Skip to main content
Every endpoint in this reference is also a tool on the Dueflow MCP server:
The server is the public API with a different transport. A tool call is dispatched as the REST request it stands for, so scopes, role ceilings, organization policy, rate limits and the activity log all apply exactly as they do over HTTP – there is nothing extra to enable, and nothing an assistant can do that the same token couldn’t do with curl.

​
Connect from ChatGPT or Claude

ChatGPT and Claude can’t paste a token; they sign in with OAuth. Add Dueflow as a custom connector (MCP server) with the URL above and choose OAuth if you are asked. The client discovers everything else from the server.
1

Sign in to Dueflow

You are sent to dueflow.co to sign in with your usual account. Nothing is shared with the assistant until you approve the next screen.
2

Approve the connection

Pick the organization the assistant may act in and tick the scopes it may use. Scopes your role can’t hold, or that the organization has blocked, are shown but can’t be granted. Decline and the assistant gets nothing.
3

Ask away

The assistant now holds a short-lived access token (one hour) and a refresh token it renews silently. Every call it makes appears in the organization’s API activity log, attributed to you via the app.
The connection appears under Profile → Developer → Connected apps, with the organization, the granted scopes and when it was last used. Disconnect revokes it immediately; the assistant has to be authorized again to continue.
A connection acts as you, with personal-token semantics: change roles and it narrows the same minute, leave the organization and it stops working. Scopes are re-evaluated every time the token is refreshed, so a connection can lose scopes over time but never gain them.

​
Connect with a bearer token

Clients that can send a header – Claude Code, Cursor, scripts, anything headless – skip OAuth and use a personal or service token directly:
This is the only way a service token reaches the MCP server. OAuth is a person consenting, so it only ever issues personal-token access; an integration that has to survive officer turnover uses a dfs_ token in a header, as it would for REST.

​
Tools

tools/list returns one tool per endpoint the token is allowed to call, named after the operation in snake_case – GET /v1/members is get_members, PATCH /v1/members/{memberId} is patch_members_by_member_id. Path parameters, query parameters and body fields are all arguments of the tool; the input schema is the endpoint’s, so the reference page for an endpoint documents its tool too. Tools the token’s scopes can’t call are omitted rather than listed and refused, so an assistant never plans around something it can’t do. An API error inside a call – validation, insufficient_scope, not_found – comes back as a tool result with isError: true and the same error body as REST, not as a transport failure.

​
For MCP client authors

The server implements the Streamable HTTP transport, statelessly: POST JSON-RPC to the URL above with a bearer; there is no session header and no server-to-client stream (GET returns 405). An unauthenticated request returns 401 with the protected-resource metadata the MCP authorization spec requires:
Authorization server metadata (RFC 8414) is at https://dueflow.co/.well-known/oauth-authorization-server. In short: Access tokens are ordinary personal tokens, so everything in Authentication about live roles, organization policy and revocation applies to them unchanged.