API Report Card · Workflow & CRM · Methodology v1.1
Process Street
Where the points came from.
Five categories, each worth a fixed share of the 100 points. A category earns the fraction of its checks it passes, times its maximum.
Functional Coverage
Design & Reliability
Access Control
Docs & AI-Ready
Access & Cost
Letter grades are absolute, never curved.
The same numeric bands apply to every platform. Nothing here is scored relative to the rest of the board.
What this means for you.
One paragraph per category, in plain language.
1 · Functional Coverage
The strongest part of the API. Everything the product does, the API can do: start a checklist, tick tasks off, write form answers, assign people, build and publish templates, manage data sets. The writes were proven on a live account rather than taken from the docs. The weak spot is being told when things change. You get an event when a run starts, when a task is ticked, and when a run finishes, and nothing else. There is no changed-since filter anywhere, so anything outside those events means re-reading the whole list and comparing it yourself.
2 · Design & Reliability
The weakest half of the API, and the reason the grade sits where it does. The shape is fine: clean REST, sensible pagination with a documented sort order, and rate-limit headers that tell you exactly when to back off. Three things will cost you real engineering time. Retry safety is broken: the documentation promises that sending the same start-this-checklist request twice will not duplicate it, and in live testing it created two runs. The form-field data is loosely typed in both directions, and the docs describe the read format incorrectly. And there is no version check, so two systems writing the same run will silently overwrite each other.
3 · Access Control
The category with real operational risk. Outside Enterprise, every API key is a full organization administrator. There is no read-only key and no way to limit a key to one workflow or folder, so any key you issue could delete every workflow in the account. You do get two real controls: you can hold several separate keys, and you can revoke any one of them instantly yourself. Treat every key as a master password and give each integration its own.
4 · Docs & AI-Ready
A genuine strength. The full machine-readable spec is public and free, no login and no sales call, so an AI coding tool can consume the whole API in one file. Process Street also runs its own MCP server, which means Claude can drive the account directly without you writing an integration at all. That is unusual and genuinely valuable. Cautions: many write endpoints have no worked example, the AI-specific files are only link indexes, and the overview contains at least two statements that live testing disproved.
5 · Access & Cost
Getting in the door is easy and free. You create keys yourself, and the whole API works on the entry plan. The published plan matrix lists 50 API calls a month on Startup, which would not support real automation. During this run about 90 calls went through on a Startup account with no payment-required error, so that cap was not enforced on that one organization; the run does not establish how it is applied generally. Confirm your own quota before building anything business critical, and note that scoped keys are Enterprise only.
Every check, and why it scored that way.
The same 27 checks are applied to every platform. What changes is which are N-A and what the core objects mean for that kind of software. Each mark below is quoted from the run's own report.
Category 1 · Functional Coverage
13.1 / 15Object coverage
weighted coverage = 93% (20.5 of 22 weighted points; no critical object absent). Full-CRUD critical objects [frozen spec: /workflows, /workflow-runs, /workflow-runs/{id}/tasks/{taskId}, /webhooks, /scheduled-workflows]. Deductions: Users scored 0.5 — only GET /users exists (live: returned the org user list, no write verb defined); Reporting/exports scored 0.5 — only GET /work/stats.
Core operational actions
weighted coverage = 100% (15 of 15). Every mutable item can be created or updated: createWorkflowRun, updateWorkflowRun, updateTask, batchUpdateFormFieldValues, createWorkflow, assignWorkflowRun, createDataSetRecord, createPage. Observed live (controlled live): POST /pages → 201; PUT /pages/{id} changed description from BEFORE-STATE to AFTER-STATE-updated-by-api-test, confirmed by fresh GET; POST /data-sets → 201; POST /data-sets/{id}/records → 201; POST /workflows → 201; POST /workflow-runs → 201.
Delete or lifecycle actions
weighted coverage = 100% (15 of 15). deleteWorkflowRun + undeleteWorkflowRun, run status transitions (Active/Completed/Archived), deleteWebhook, unassignWorkflowRun/unassignTask, publishWorkflowRevision, deleteDataSetRecord, deletePage, completeOneOffTask/uncompleteOneOffTask, upsertApproval. Observed live: DELETE /pages/{id} → 204 then GET → 404 NotFound; DELETE /workflow-runs/{id} → 200; DELETE /workflows/{id} → 204; DELETE /data-sets/{id} → 204; DELETE /webhooks/{id} → 200.
Change notification
outgoing webhooks exist and deliver, but cover well under the yes threshold and there is no updated-since filter anywhere in the API. POST /webhooks accepts six triggers only: TaskChecked, TaskUnchecked, TaskCheckedUnchecked, TaskReady, WorkflowRunCreated, WorkflowRunCompleted [frozen spec, CreateWebhookRequest.triggers enum]. There is no event for run archived/deleted, assignment changes, form-field value changes, data-set record changes, or template publication. Weighted push coverage over the fixed critical-plus-important state changes = 45%. Delivery was verified live (see step 8). Marked partial rather than no because the written no condition — "no reliable way to detect the critical state changes" — is demonstrably false: run-created, task-completed and run-completed are all reliably pushed, and documented status filtering plus audit.updatedDate on every record lets the remaining run-state changes be polled. See disclosed disagreement below.
Category 2 · Design & Reliability
5 / 10Modern API conventions
resource-oriented REST over JSON with standard verbs (62 GET, 35 POST, 29 PUT, 24 DELETE across 82 paths), described by OpenAPI 3.1 [frozen spec]. Confirmed live throughout.
Consistent typing
(resolved against evidence; see disagreement 1) — most of the surface is well typed (167 integer, 450 boolean declarations; size/sizeBytes/total are integer/int64; Data Set cells are correctly oneOf [null, number, string], and a Number column written as 42 came back as JSON 42, not "42" [live GET /data-sets/{id}/records]). But the core form-field payload — the primary data path of a workflow product — fails on both directions. On write, UpdateMultipleFormFieldValuesRequest.fields[].value is declared "type": "string" and nothing else, so a Number form field must be submitted as a string. On read, SimplifiedFormFieldValue.data declares no type at all, and its description ("a string for Text, a number for Number, an array of selected option keys for MultiChoice") is contradicted by every live read, which returned an object wrapper: {"data":{"value":"skevin2014@gmail.com"}}, {"data":{"value":"2022-09-07T15:00:00.000Z","timeHidden":true}}, {"data":{"values":[…]}}. The same concept — a user-entered value — is therefore typed as a bare string on form fields and as a typed union on data-set cells. This satisfies the no condition on two counts (core fields stringly typed; types vary across endpoints), and is excluded from partial, which requires inconsistencies "confined to non-core fields".
Structured errors
a proper structured envelope exists with a stable machine-readable enum of 11 values (BadRequest, Unauthorized, PaymentRequired, Forbidden, NotFound, MethodNotAllowed, Conflict, PayloadTooLarge, Validation, RateLimited, InternalError) and correct HTTP status semantics. The exact limitation: live testing showed errorCode and requestId are populated only on handled application errors and are absent on the most common failures. GET /workflows/ZZZ… → {"error":"…","errorCode":"NotFound","requestId":"nF8thAn7e7lyvH8iKG9EOg"}, but GET /workflows/not-a-real-id → {"error":"Path parameter [workflowId] must be a 22-character Muid identifier."} (400, no code), ?status=Bogus → 400 no code, PUT /workflows → {"error":"Method Not Allowed"} (405, no code), POST /workflows {} → {"error":"Field [folderId] is required.; Field [name] is required."} (400, no code and no details object despite the spec documenting field-path details for Validation errors), and GET /does-not-exist returned an entire HTML error document embedded inside the JSON error string. Error shapes vary across endpoints.
Duplicate prevention
the spec's own overview states: "For workflow runs, attach a referenceId on create — calling createWorkflowRun twice with the same referenceId will return the existing run instead of creating a duplicate." CreateWorkflowRunRequest contains no referenceId property at all (only workflowId, name, dueDate, shared), and on the two other schemas where referenceId does appear it means something unrelated — "Version prefix used when version control is enabled". Live test (controlled live, 2026-08-31): the identical POST /workflow-runs body carrying referenceId: "apitest-idem-2026-08-31" was sent twice; both returned 201 and created two distinct runs, gKCX9EluQuU5QbFUG4pDeA and v-lFQKfHQhFOQ717RkNCvQ, confirmed by GET /workflow-runs/list?workflowId=… returning 2 records. No idempotency-key header is documented anywhere. PUT and DELETE are naturally idempotent (verified live: repeat PUT → 200 with unchanged state; repeat DELETE → 404), but the check excludes naturally idempotent operations from earning credit.
Graceful handling under load
documented: "If you receive a 429 response, wait for the duration specified in the Retry-After header before retrying." Live, every response carried machine-readable limit headers: X-Api-Key-Rate-Limit-Limit: 200, X-Api-Key-Rate-Limit-Remaining, X-Api-Key-Rate-Limit-Reset, the IP-level equivalents (X-Ip-Rate-Limit-Limit: 1000), and Retry-After.
Pagination for large collections
(corrected during reconciliation; see disagreement 2) — documented opaque cursor named _ plus a links[] array carrying a fully-formed next href, present on 29 operations, and a stable ordering guarantee documented per endpoint on 18 list operations: /workflows "sorted by name", /workflow-runs/list "sorted by creation date (newest first)", /users "sorted by name", /pages "sorted by name", /data-sets "sorted in order of creation date", /tasks "sorted in order of due date", /comments "sorted by creation date (newest first)", task and widget lists "ordered by position". Live traversal of /workflows completed the whole collection with zero id overlap between pages (page 1 = 20 items → follow next → page 2 = 0 items, next absent, terminated). Noted but not disqualifying under the check's wording, which requires a next-page token or a total count: there is no total-count signal, page size is fixed (?limit=3 was silently ignored and returned 20), and a next link is emitted even when the following page proves empty.
Bulk or incremental export
top-level collections can be extracted by cursor-paging list endpoints without per-record calls. The exact limitation: there is no updated-since/modifiedSince parameter anywhere (the API's complete query-parameter vocabulary is _, workflowId, status, type, name, assigneeEmail, workflowRunId, taskId, createdById, fields, columns, folderId, taskType, search, dueDateFrom, dueDateTo, snoozeStatus, includeCompleted), no dedicated bulk or async export path, and the operationally valuable data — form-field values — is not returned inline on run lists and requires one call per run (GET /workflow-runs/{id}/form-fields, verified live). POST /data-sets/{id}/records/import is inbound import, not export; Enterprise BI Integrations are a separate Enterprise-only product.
Webhook security and delivery reliability
a retry policy is documented ("If you take too long to return a successful response, we will attempt to send the webhook again, for a maximum of 3 tries") and delivery was observed live: after POST /workflow-runs, the operator-controlled server logged POST /ps-webhook-test HTTP/1.1" 404 … "ProcessStreet/1.0" at 19:19:54Z, two seconds after the event. The exact limitation: there is no payload signing of any kind — zero occurrences of signature, HMAC or secret in the frozen spec, CreateWebhookRequest accepts only url, triggers, workflowId, taskId with no secret, and the webhooks help article describes no verification mechanism — and there is no replay or idempotency guidance for consumers.
Concurrency and conflict control
zero occurrences of ETag, If-Match or If-None-Match in the frozen spec; no version or revision-lock field on mutable resources; and no operation declares a 409 response (the only declared response codes across all 150 operations are 200, 201, 204, 400 and default). Conflict exists solely as an unused value in the error enum, with no documented conflict semantics for any endpoint, and no documented concurrency limits. Concurrent writes are last-write-wins with nothing to detect a lost update.
Versioning and backward compatibility
an explicit version identifier exists in the path and the spec (/api/v1.1, info.version: "1.1"). The exact limitation: there is no backward-compatibility policy, no definition of breaking versus non-breaking change, and no deprecation window or notice mechanism — zero occurrences of deprecat* or sunset in the frozen spec, and none in the help centre.
Request traceability
(corrected during reconciliation; see disagreement 3) — every live response, success and error alike, carried x-process-street-request-id (e.g. ht29sF4qKqvZIq_HMeJMig), and where a requestId body field appeared it held the same value. The exact limitation: the two halves never coincide. The header that is present on 100% of responses is documented nowhere — x-process-street-request-id occurs 0 times in the frozen spec, and only 2 of 150 operations declare response headers at all. The identifier that is documented for support use ("Per-request correlation ID. Include this when contacting support so we can find the request in our logs") is the ErrorInfo.requestId body field, which appeared on only 1 of the 6 deliberate errors. So there is no single identifier that is both always present and documented as usable with support.
Service availability and status transparency
a public status page exists at https://status.process.st/ with per-component status ("Process Street Web Application", "Process Street APIs") and a dated incident-history section. The exact limitation: it publishes no uptime percentage and no SLA figures.
Category 3 · Access Control
3.1 / 5Read-only credentials
no read-only role or credential exists. The four org roles are Admin, Builder, User and Guest, and none is view-only: a User is for "people who only need to work on tasks and workflow runs assigned to them", and even Guests can still act on assigned tasks [https://www.process.st/help/docs/user-permissions/]. Observed in-app 2026-08-31: the graded credential's own profile page reads "API Key #4 — Admin of RL Property Management", with all three library folders "Inherited: Edit & View All". The key used for this run therefore had full write authority over the entire organization.
Scoped credentials
a genuine fine-grained scoping mechanism is documented: restricted API keys can "scope an API key user's access to specific resources — workflows, pages, forms, files, or data sets". The exact limitation: it is Enterprise-only — "Restricted API keys are available on Enterprise plans" — and it was confirmed unavailable on the graded organization. On the Startup org the Users & Guests role filter offers only All Users / Admins / Builders / Users / Guests with no "API Key Users" option, API key users do not appear in the member list at all (the org reports "1 ADMIN(S), 0 BUILDER(S), 0 USER(S), 0 GUEST(S)" while four keys exist), so a key's role cannot be changed and every key is an unrestricted org Admin.
Multiple keys
four distinct, individually labelled keys were observed on the Integrations page, each with its own label field, masked value, Copy/View controls, access page and delete control, alongside a "New API Key" button [in-app observation, app.process.st/organizations/manage/integrations, 2026-08-31].
Rotation and revocation
self-serve, no support ticket: each key row carries its own "Delete API Key" control for immediate revocation, keys are freely relabelled, and new keys are created self-serve from the same screen, so rotation is delete-and-reissue by the administrator alone [same observation].
Test and production isolation
no sandbox or separate test environment is offered or evidenced; there is a single production host, https://public-api.process.st/api/v1.1. Excluded from the maths.
Category 4 · Docs & AI-Ready
3.8 / 5Complete self-serve reference
the reference is public, requires no login, and is genuinely usable: a rendered reference at /docs/index.html (with a <noscript> fallback linking the raw spec, so it is readable even without JavaScript), and all 150 operations carry a summary or description. The overview documents authentication, pagination, ID format, date handling, errors, retry semantics and rate limits. The exact limitation: worked request examples are missing for most operations — only 42 of 150 have request-body examples, and core write endpoints including createWorkflowRun lack one; response examples are largely inferred from schema-level examples (570 occurrences across 148 of 358 schemas) rather than given per operation. Separately, and noted here without being scored twice, the overview's idempotency guarantee is factually wrong (graded in C2.4) — a developer or AI agent building from this reference would ship an unsafe integration believing it was protected.
Reliable machine-consumable integration path
a complete, maintained, publicly downloadable OpenAPI 3.1 specification suitable for code and tool generation (JSON 1,588,304 bytes; YAML 2,298,618 bytes; 82 paths, 150 operations, 358 schemas), retrievable unauthenticated. Independently, Process Street operates a first-party MCP server at https://mcp.process.st/ that "supports most Process Street API endpoints as tools", including write operations. Either alone would satisfy this check.
AI-readable documentation
(resolved during reconciliation; see disagreement 4) — https://www.process.st/llms.txt (HTTP 200, 8,995 bytes) carries a dedicated "## API & Developer" section, and https://www.process.st/help/llms.txt is a 211,972-byte help corpus. The exact limitation: both are link indexes with one-line blurbs, not retrievable API content — the root file devotes 5 links to the API, and only about 6 lines of the 212 KB help file touch the API at all; there is no per-endpoint Markdown and no plain-text documentation corpus; llms-full.txt returns HTTP 404. The OpenAPI spec and the MCP server are genuinely strong AI-consumption paths, but both are already credited in C4.2, and crediting the same artifacts again here would double-count them against the methodology's own integrity check.
Kept current
the first-party release blog carries dated, API-specific entries and is current: "105 New API and MCP Endpoints" (2026-05-21), "Introducing Process Street's MCP Server" (2026-01-27), plus "Form Field APIs Now Support Table Fields (Read and Write)", "Easily Sync External Data Sources into Data Sets with the New CSV Import API Endpoint" and "Upload Files Via the API"; the newest post is 2026-07-15, about six weeks before this run. Noted: the dedicated "New API Endpoints" page is stale at 2025-07-01, and there is no deprecation guidance (graded in C2.10, not here).
Category 5 · Access & Cost
11.3 / 15Self-serve API key
an administrator creates a key from the Integrations page with no sales call, support ticket or approval step: "To create an API key you must be an administrator", "you can generate and name a new API key from the integrations page in your organization manager area" [https://www.process.st/help/docs/process-street-api/]. Confirmed in-app: a "New API Key" button sits directly above four existing keys, and the supplied key authenticated live on the first attempt.
Not commercially gated
API access itself is included on every tier, not locked behind a premium plan: "Available on All plans" [help/docs/process-street-api/] and "The REST API is available on all plans" [llms.txt]. This was exercised live on a Startup organization (Billing page: "T5K Startup - Monthly", Active). The exact limitation: the published plan matrix gates meaningful capability by tier — Startup "Public API (50 calls/month)", Pro "Custom no. of API calls/month", Enterprise "Unlimited Public API access" — and two capabilities that materially affect safe automation are Enterprise-only: restricted (scoped) API keys and the BI/Reporting integration. A 50-call monthly allowance would not support any real automation. Observation, recorded for accuracy: roughly 90 calls were made during this run on the Startup plan with no PaymentRequired (402) response, so the published cap was not enforced in practice on this organization; the enforced limit observed was a per-key rate limit of 200 requests, not a monthly quota.
What works
- All eight live-test steps run against a live account, writes and a real webhook delivery included
- Graded three independent times, every disagreement resolved against the evidence
- Full OpenAPI 3.1 spec, public and free, no login required
- A first-party MCP server, so Claude can drive the account directly
- API access included on every plan, with self-serve keys
What to watch
- Documented duplicate prevention does not work: the same request created two runs
- Every API key is a full organization admin outside Enterprise
- Form-field data is loosely typed, and the docs describe the read format wrongly
- No changed-since filter anywhere, so no incremental sync
- Webhooks carry no payload signature of any kind
The bottom line for a property manager
Process Street's API can do essentially everything the product can do, and the writes were proven on a live account rather than taken on trust. The documentation is a real strength: the complete machine-readable spec is public and free, and Process Street runs its own MCP server, so Claude can drive an account with very little custom code. Three things should shape how you use it. Retry safety is broken, so build your own duplicate guard. The documentation is wrong in places that matter, so build against observed behaviour and test each endpoint yourself. And outside Enterprise every key is a full organization administrator, so give each integration its own key and revoke precisely. It is not a PMS, a bank, or a trust accounting system. It is the procedure layer that runs on top of whatever holds your properties, leases and money, and it does have a genuine property management offering, though that comes from templates rather than any property-specific objects in the API.
Check it yourself.
Both files behind this page, in full.
Process Street’s full report
The complete markdown report this page is built from, including the evidence packet, the run metadata and every check in full.
Download the Process Street reportThe grading file
The exact rubric behind every score on this page. Same file, every platform. Run it yourself and compare.
Download the methodologyFound a factual error in your grade?
Tell us and we will fix it. Every mark on this page traces to a specific piece of first-party evidence or a live API call, and the full report is published so you can see exactly what was checked and what it was checked against.
Confirmed factual errors are corrected immediately.
Everything else waits. We do not rescore piecemeal on request, because a board where some vendors have been re-run and others have not is not a fair comparison. Shipped improvements, changed documentation and disagreements about judgement all go into the next full rerun.
Contact us with a factual errorMethodology inspired by SaaStr’s AI Agent API Report Card. Sponsored by Column.