Skip to main content
PartFinder authenticates every request with an API key passed as a Bearer token in the Authorization header. Keys belong to your organization, not to a team member, and keep working when someone joins or leaves your team.

Creating an API key

1

Open the API Keys settings

Sign in at console.partfinder.dev and open Settings → API Keys. Anyone can create an account at console.partfinder.dev/sign-up. Keys belong to your organization.
2

Create a new key

Click Create API key and give it a descriptive name that identifies its purpose and environment (for example, production-erp-integration). A name cannot be changed later; the description and expiration can.
3

Copy the key immediately

Copy the key as soon as it appears. The console shows it only once and cannot retrieve it afterward. Store it somewhere secure before closing the dialog.
Name each key after the system that uses it, for example production-erp-integration or staging-bom-service.

Sending the key

Include your API key in the Authorization header of every request using the Bearer scheme:
The /v1/ping endpoint is the fastest way to confirm your key is wired correctly before calling anything that costs credits.
A successful response confirms the key is valid and returns the organization it belongs to:

Serving your own customers

If you offer PartFinder inside your own product, give each of your customers its own key, created by your code with POST /v1/keys and one of your organization’s own keys:
The response carries the new key’s secret once, and an end_customer_id naming that customer.
  • Each customer sees only its own data. Requests for quote, BOMs, searches and comparisons made with a customer’s key belong to that customer: its keys list and read only those, and another customer’s id answers 404. Your organization’s own keys see everything.
  • Requests for quote name the customer. When a request for quote sent with a customer’s key names no requester company, the customer’s company is used.
  • Replies are told to the customer. A request for quote sent with a customer’s key needs notify_email: that address alone is emailed when the supplier replies, never your organization’s people. Without it the request answers 400 and nothing is sent.
  • Several keys, one customer. Send end_customer_id instead of company to add a key to a customer you already created. To replace a leaked key, create the new one, move the customer over, then revoke the old one with DELETE /v1/keys/{id}. The customer’s data stays.
  • Rate limits. Each customer can make as many calls as your organization, and your organization’s limit applies to all of them together. See Rate limits.
  • Customer keys cannot create, list or revoke keys (403 key_not_allowed).
GET /v1/keys lists your customers’ keys, never their secrets. The key_id in every response tells you which key served the call.

Revoking keys

Revoke a key at any time from Settings → API Keys in the console: click the key’s Revoke button, type Revoke to confirm, and click Revoke key. Every member of your organization sees its keys and can create one. Members can edit, rotate and revoke the keys they created; admins can change any key. See Console for roles and inviting teammates.

Rotating keys

The Rotate button on a key creates a replacement (same name, with a rotation stamp), shows its secret once, and revokes the current key. Update your integration with the new secret within a minute: the previous secret keeps working that long, so there is no gap. A key you created for one of your customers keeps belonging to that customer after it is rotated.
Revocation takes effect within about a minute; until then the key may still be accepted. Unknown, revoked and expired keys all return 401 invalid_key.

Key security

Follow these practices to keep your API keys secure:
  • Use environment variables. Store keys in environment variables or a secrets manager. Never hardcode a key in source code or commit one to version control.
  • Rotate keys regularly. Rotate keys on a schedule, and immediately when a team member with key access departs.
  • Use one key per environment. Create separate keys for development, staging, and production so you can rotate or revoke one without affecting the others.
  • Limit key distribution. Only the systems that need to call the API should have access to the key. Avoid sharing keys between unrelated services.