Overview
What a job is and the rules that apply to all of its endpoints.
Everything that depends on the marketplace runs in the background, as a job. The API answers right away and the work goes on afterwards. You track the job by its id.
The states of a Job and who creates each type, as diagrams: States and events.
There are six types; the table of who creates each one is in States and events. One of them is connection.sync, started for each connected account. Its id arrives in the connection.created event (data.syncJobId), and in the connection.updated of a reconnection.
How to follow a job to the end: Tracking jobs.
Endpoints
| Method | Path | What it does |
|---|---|---|
GET | /v1/jobs | List jobs |
GET | /v1/jobs/{id} | Get a job |
GET | /v1/jobs/{id}/items | List items |
All of them require Authorization: Bearer mk_your_api_key. See Authentication.
States
status | Meaning |
|---|---|
queued | waiting in the queue |
running | in progress; processed moves item by item |
completed | every item succeeded |
partial | some succeeded; see the items with failed |
failed | no item succeeded; error sums it up |
Items
Each job has items, one per resource, each with its own status, result and error. Items keep the job order (index), not newest first like the other lists.
Internal jobs
Our own maintenance (for example, token refresh) also runs as jobs, but they are not in the API: an internal job returns 404, the same as a job from another account.