Credentials & tokens

There are two different kinds of access here, and most paths need little or nothing. This page is the one place that explains both.

Surface	What it needs	Where it comes from
Docs MCP (remote)	nothing	Public — …/mcp, no token.
Local stdio (either MCP)	nothing	The mock runs in-process; no token, no credentials.
The mock API (build a client)	an api_key + an integration id	Pre-loaded demo credentials, or the OAuth install flow.
Rails MCP (remote)	the shared MCP_ACCESS_TOKEN	Provided with your evaluation invite.

You can do a lot with zero secrets

Connect the Docs MCP (public), run either MCP locally over stdio (no token), or call the API with the pre-loaded demo credentials below — none of these need anything from anyone.

1. API credentials — to build a client

Every API call (except the install call) carries two headers:

Authorization: Bearer <api_key>
Partly-Integration-ID: <integration_id>

You can get these two ways:

1. Use the pre-loaded demo credentials (zero setup). The sandbox ships ready-to-use repairer credentials, so you can make a real call immediately — no signup, no dashboard:

   curl -s https://partifact-mock-rails.thanhvuttv.workers.dev/api/2026-01/repairer.jobs.get \
     -H "Authorization: Bearer partly_demo_repairer_3f8a1c0d9e2b4a67b1c2" \
     -H "Partly-Integration-ID: 0c000000-0000-4000-8000-000000000001" \
     -H "Content-Type: application/json" \
     -d '{"identity":{"external":"CCC-2026-04817"}}'

   A seeded supplier credential also exists (for the confirm step); see the Authentication reference.

2. Provision your own programmatically (the OAuth install flow). A real integration shouldn’t use hand-pasted keys. The install call — integrations.insert — is the one method that takes no auth headers; it exchanges an OAuth grant for a fresh api_key + integration_id. This is exactly the “provision without a human” path the developer eval measures. Full flow: Authentication →.

Why the key and header still say “partly”

The Partly-Integration-ID header and the partly_… key prefix are wire-contract identifiers — Partifact faithfully mirrors the shape of a real parts-procurement API, and those identifiers are part of that protocol. They are the contract, not branding; renaming them would make the mock unfaithful. Everything else here is Partifact’s own.

2. The Rails MCP access token — to connect the remote runtime MCP

The Rails MCP mutates stateful, per-tenant sandboxes, so its remote endpoint is gated by a shared MCP_ACCESS_TOKEN. (The Docs MCP is public and needs none.)

1. Where to get it. The token is provided with your evaluation invite. It only gates the endpoint against random traffic — it is not per-user. If you’re reviewing this without an invite, see the no-token options below.

2. Where it goes. In the URL path, so a connector UI that only takes a URL still authenticates:

   https://partifact-rails-mcp.thanhvuttv.workers.dev/mcp/<MCP_ACCESS_TOKEN>/<your-slot>

   Or as a header (Authorization: Bearer <MCP_ACCESS_TOKEN>), keeping <your-slot> in the path. Either way, pick any <your-slot> name for a private sandbox — see Rails MCP.

3. Keep it out of anything you commit. It’s a shared secret; don’t check it into a .mcp.json or paste it into a public page.

No invite? You can still try everything

• Read the docs as tools → the public Docs MCP (no token).
• Operate the lifecycle → run the Rails MCP locally over stdio (mock in-process, no token, no slot).
• Build a client → use the demo API credentials above, or the install flow.

What each setup path actually needs

claude.ai connector

Docs MCP: just the URL. Rails MCP: the URL with your MCP_ACCESS_TOKEN + slot. → Set up

Claude Desktop / Code (local)

Nothing — build the stdio servers and point Claude at them. No token, no credentials. → Desktop · Code