This article presents possible use cases and corresponding sample flows that you can support. It provides a useful starting point as you plan your implementation.
A provider needs to see which engagements are waiting on them and what each client asked for, so they can decide what to pick up next. The project carries the client's request, so building this list doesn't require retrieving any briefs.
To build a provider's work queue:
status to retrieve the projects to act on, such as NEW for the requests awaiting a first response.briefDescription on each returned project to see what the client asked for.expirationDate on each project to see how long the provider has to respond before a project that's still NEW expires.contactId to the Contacts API to retrieve the client's name and contact details.A provider has agreed to take on a client's request and works it through to delivery. Each call returns the updated project, including the revision needed for the next call.
To take an engagement from first contact to delivery:
status and revision.status must be NEW, CONTACTED, or IN_DISCUSSION.completedProjectSnapshot, metasiteId, or both as proof of delivery, and optionally serviceName and budget to record the work's category and what the client agreed to pay.Not every request turns into work. A provider closes out an engagement they won't be delivering, recording why so the outcome is captured.
To end an engagement that isn't going ahead:
status and revision.cancellationInfo, choosing the reason that fits, such as CLIENT_NOT_RESPONDING or BUDGET_IS_TOO_LOW, and adding any details in additionalInfo.Cancellation is final, so a canceled project can't be restarted.
After a project is delivered, the client can rate and review it. A provider replies to that feedback in public.
To respond to a client's review:
status is COMPLETED and that review exists without a reply.reply text and the current revision.A review supports a single reply, which can't be changed once submitted.
Last updated: 25 August 2026