Introduction
Describe the access you need and who will use it. This form records the request only. Do not paste an API key, password or token here, because the owner issues credentials in the system that owns the API.
API access request: record the need, not the secret
An API access request should say who needs access, why, to which areas, and in which environment, so that the owner can decide the smallest scope that does the job. The request records the decision; it does not create a key, role or account, and it should never carry a secret. Start with test access and a date to review it, and request production access separately once the integration has been checked.
Words for the respondent
Confirmation
Thanks. Your request is saved. The owner reviews it and sets up access in the system that issues credentials, then contacts you there.
Which endpoints or resource areas do you need?
Name the areas, such as read orders or read customers. Do not paste keys, tokens or example credentials.
Review or end date
The date this access should be checked again or removed. Use the end of the project if it has one.
Field blueprint
Eleven fields that give an approver what to decide
| Field | Type | Required | Why you ask it |
|---|---|---|---|
Requester name | Short text | Required | The person who will use the access and who the owner can contact about it. |
Organization or teamFor example: Partner integrations team | Short text | Required | Shows which project or partner the access serves, so it can be reviewed when that project ends. |
Contact email | Required | Where the owner sends questions about the request. Credentials are not sent to this address through the form. | |
Access typeRead-onlyRead and writeAdministrative (approved by the API owner) | Single choice | Required | Sets how much review is needed. Read-only and read-and-write access are different decisions. |
EnvironmentTest environmentProduction | Single choice | Required | Test access usually comes first. Production access should be a separate request, made after the integration works. |
What will you use the access for? | Long text | Required | The business reason in plain words. An approver cannot judge a request that says only integration. |
Which endpoints or resource areas do you need?For example: read orders, read invoices | Long text | Required | The narrowest set that does the job. Access granted for everything tends to stay that way long after it is needed. |
Personal or customer data involved?No personal dataYes, contact detailsYes, account detailsYes, other personal data | Single choice | Required | Changes the review. Name the category of data, never the values themselves. |
Expected requests per dayFor example: about 2,000 | Short text | Optional | Lets the owner plan limits before the integration goes live. |
Review or end date | Date | Required | Access without an end date tends to outlive the project it was granted for. |
Approver | Short text | Required | Names the person whose yes is needed, so the request does not stall in a shared inbox. |
Try it
Try the request as the person who needs access would
After a response arrives
From request to access, in your own systems
Requests wait for the scheduled job
Notifications to the creator follow the hourly processing run in production, not the submission itself. Plan approvals with that lag in mind, and ask requesters to flag urgent needs directly.
Read each request in the grid, then decide
Check the access type, the environment and the data category in the grid. Then approve, narrow the scope or ask a question in your own process, and record the decision where your access system keeps its history.
Issue credentials in the system that owns the API
Create the key, role or account there, and send the credential through your usual secure channel. Never send it by replying to the request, and never copy it into an export.
Keep an access register from exports
Export the responses to CSV to keep a register of who has access and why. Remove a row when the access ends, and check the review date before it passes.
Mistakes to avoid
Requests that create access nobody can explain later
Requesting admin access by default
Asking for everything keeps the approval simple and the exposure large. Start with read-only access in a test environment, and add permissions when a real need appears.
Pasting a secret into the request
A key pasted into a form has been copied into the responses, the grid and any export. Ask for the access, and let the system owner issue the secret through its own channel.
Leaving the end date blank
Access granted for a finished project stays open because nobody remembered it. Set a date to review it, and close the access on that date if nobody has renewed it.
Approving in a thread
An approval that lives in a shared thread is hard to find when someone asks who approved what. Record the decision beside the request, with the approver's name and the date.
Frequently asked questions
Can this form create an API key for me?
No. The form records the request and the people who will review it. The key, role or account is created in the system that owns the API, by the people who run it, and the credential should travel through a secure channel rather than this form.
Is there an API access request template I can download?
This guide lists the fields and the order to ask them in. It does not come as a Word or PDF document. Attain OS publishes the request as a link, and a CSV export gives you a register to work from.
What should an API access request say?
It should name the requester, the reason, the environment, the access type, the endpoints or areas needed, the categories of data involved, the approver, and a date to review the access. Describe the endpoints by name, and leave out any key, token or example request that contains a credential.
Should production access be requested at the same time as test access?
Usually not. Request test access first, check that the integration works with the scope you asked for, and then make a separate production request with its own approver. A single request for both makes it hard to see what was approved, and when.
Browse by category
More requests in Product & Engineering
Requests
Architecture Review Request
Requests
Design/UI Request
Applications
Beta Tester Signup
Reports
External Bug Report
Surveys
Product Feedback
Checklists
Release Sign-off
How to build it
Choose a category and a form type in the wizard. Answer three Atty Suggestions questions, then give the form a title. Atty builds the fields in the background. Edit the fields and ask Atty to refine them, then publish and share the /f/ link.
