Skip to main content
A partner can call Flowker with its own credential. In Flowker, you confine that credential to some workflows. This page shows how to choose that scope, what it reaches, and what the partner receives when it goes outside it. Every Flowker partner needs a scope.

​
Step by step

1

Choose the partner's workflows

Flowker has one restriction. The API field is the field of a scope entry; the Console shows the name in the first column.The scope catalog lists the Flowker restriction. Read it with Retrieve a product’s scope catalog for flowker.Some rules apply to every scope:
  • A request that does not name a workflow is refused. For example, a partner cannot list executions without filtering by its workflow.
  • A request that lists several workflows in a query is refused when any of them is outside the scope.
2

Give the partner its permissions and scope

Create the partner, or change it, in the Console or with the Identity API. The product slug is flowker.
  • Add the workflowId scope entry, with one or more workflows. Without it, Access Manager refuses the partner with 400 and IDE-1060.
  • Check the resources and actions. The most you can give is what the flowker-editor-role role holds in your tenant. Above that, Access Manager refuses with IDE-1043. For example, catalog with create is above that role.
A partner receives only the permissions that act on a workflow:Every other Flowker permission acts on the whole tenant, and is never given to a partner, not even the read ones, such as workflows with list or executors with read. Access Manager refuses with 400 and IDE-1056.
3

Create its Flowker application

Create the partner’s application with the product flowker. See Create the partner’s applications in the API guide, or in the Console. Send the client ID and the client secret to the partner through a secure channel.
4

Tell the partner how to name its workflows

In almost every route the partner reaches, the workflow is already in the path, in /v1/workflows/{workflowId}, so the partner sends nothing extra. Only the execution list names the workflow in a query. Every value must be inside the partner’s scope.
To read an execution, use the routes under the workflow: /v1/workflows/{workflowId}/executions/{executionId} and …/results. The routes /v1/executions/{id} and /v1/executions/{id}/results do not name the workflow, and are refused to every partner.
An execution of another workflow, asked for under the path of one of the partner’s workflows, answers 404 with FLK-0500. Nothing is read, and the answer does not say which workflow the execution belongs to.An Idempotency-Key already used to execute another workflow answers 409 with FLK-0511. Nothing is executed, and the answer carries nothing of the other execution. A new key executes the workflow, and the same key repeated on the same workflow returns the same execution.These routes do not name a workflow, and are refused to every partner: listing and creating workflows (GET /v1/workflows, POST /v1/workflows, POST /v1/workflows/from-template), GET /v1/workflows/schedule/pending-review-counts, POST /v1/workflows/preview-request, and the routes of the catalog, executors, provider configurations, dashboards, schemas, and webhooks. Use an application of your own institution for those routes.
5

Confirm that it works

This check assumes the partner has the workflows resource with the read action on Flowker, and a scope restricted to one or more workflows. Use the partner’s credential. Read a workflow inside its scope. The answer is 200:
Send the same request with a workflow outside the scope. The answer is 403 with code FLK-0004.

​
If something fails

The answer does not say whether the permissions or the scope refused the request. This is on purpose: a partner cannot use a refusal to learn which workflows exist outside its scope. For every other code, see the Flowker error list. For the refusals when you create or change a partner, see Error codes in the API guide.