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.
Sending the key
Include your API key in theAuthorization header of every request using the Bearer scheme:
/v1/ping endpoint is the fastest way to confirm your key is wired correctly before calling anything that costs credits.
Serving your own customers
If you offer PartFinder inside your own product, give each of your customers its own key, created by your code withPOST /v1/keys and one of your
organization’s own keys:
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 answers400and nothing is sent. - Several keys, one customer. Send
end_customer_idinstead ofcompanyto 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 withDELETE /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, typeRevoke 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.