Overview
- Completeness: Ask the vendor to annotate your feature list with the endpoint that exposes each item. The gaps are the answer.
- Documentation: Ask for the machine-readable specification, the error-code reference, and the changelog. Documentation quality is the cheapest proxy for API maturity you will get.
- Rate limits: Ask for per-endpoint limits in writing, and for what happens when you exceed them.
- Testability: Ask for sandbox credentials during evaluation. How a vendor handles that request is itself part of the answer.
In an AAA platform procurement, the API line in the evaluation matrix is usually one row. REST API: yes. SOAP API: yes. Both cells go green, and the evaluation moves on to redundancy models and support tiers.
Beyond confirming a vendor has a REST or SOAP API, procurement should ask whether the API covers the full feature set, whether documentation is genuinely usable, what rate limits apply, and whether the API can be tested before signing. These four follow-ups reveal the integration risk that a simple API checkbox misses.
That one row is where a large amount of future integration risk gets filed away unexamined. Whether a vendor has an API tells you almost nothing about whether you can build what you will need in year two – when you are automating provisioning, wiring the AAA (authentication, authorization, and accounting) platform into a customer relationship management (CRM) system that was not chosen at signature, or pulling accounting data into an analytics stack that did not exist during the request for proposal (RFP).
What follows are the four follow-ups that belong underneath that row, written for procurement and integration engineering to work through together, and applicable to any vendor’s platform, including ours.
Does the API actually cover the full feature set?
The most common mistake in API due diligence is treating the feature list and the API reference as descriptions of the same thing. The feature list describes what the platform can do when a human operates it. The API reference describes what you can automate, and on many platforms the second set is smaller than the first. The cause is usually unglamorous: products that grew a management interface first and an API afterwards expose the objects the vendor’s own integration projects needed, in the order those projects arrived. Everything else stayed behind the interface.
One procurement move surfaces this in an afternoon. Send the vendor your feature requirements list and ask them to annotate each row with the endpoint that exposes it. Four answers are worth reading closely.
- Read-only, or read and write? Retrieving a policy through the API is not the same as creating or modifying one, and provisioning automation needs write access.
- Single-record or bulk? An endpoint that creates one subscriber at a time is a different tool from one that accepts a batch. Migration and daily provisioning both care.
- Configuration as well as data? Subscriber records are almost always exposed. Realm configuration, policy definitions, network access server (NAS) entries, and attribute dictionaries often are not – which leaves the parts most likely to change stuck in manual operation. This is the difference between a platform you can automate and one you can only administer, so ask specifically about realm and policy configuration, not just subscriber provisioning.
- “Available via professional services”? That phrasing describes a services engagement, not an API, and belongs in a different column of your evaluation.
Map the answers against the integrations you already know you need, then against the ones you can anticipate.
Is the documentation actually usable?
Documentation quality is the most reliable proxy available for how much an API is really used. APIs that many customers integrate against accumulate good documentation, because every gap generates a support ticket until somebody writes the missing page. APIs that mainly exist so a vendor can answer “yes” on an RFP do not.
Ask for the documentation itself during evaluation – not a link to a description of it – and check five things.
- A machine-readable specification. An OpenAPI 3.0 or Swagger definition your engineers can import straight into their tooling and start making calls against. A PDF is not this.
- Request and response examples for every endpoint – including errors. Happy-path examples are easy to write. Documented failure responses are what an integration actually has to handle.
- A documented error-code reference. Generic HTTP status codes with no vendor-specific detail leave your team guessing at causes in production.
- Authentication documented end to end. The mechanism, token lifetime, refresh behavior, and credential rotation. Rotation is the one most often missing, and the one your security team will ask about.
- Versioning, deprecation policy, and a changelog. These tell you what happens to your integrations when the vendor ships a new release, which, over a five-year term, matters more than any single endpoint.
Two smaller signals: documentation released only under NDA after signature asks you to evaluate it after the decision, and a changelog that stops two years ago tells you something regardless of what the roadmap slide says.
What are the rate limits and throttling rules?
Rate limits govern how many API requests the platform will accept in a given window. Ask for the documented limit per endpoint, the scope it applies at, and the platform’s behavior when the limit is exceeded – in writing, before signature.
Picture the migration weekend. The cutover plan calls for bulk-loading several hundred thousand subscriber records through the provisioning API overnight, and at 02:00 the job starts failing because an undocumented limit of a few hundred requests per minute is doing exactly what it was configured to do. Nobody asked, because rate limits are not on the standard checklist.
The detail matters. A 429 Too Many Requests response with a Retry-After header is a system telling your integration how to behave. A silent drop, a timeout, or a truncated response will cost you a night of debugging. Also ask whether sandbox and production limits differ, whether they are contractual or tunable, and whether bulk endpoints carry separate allowances.
One distinction prevents a common and expensive mix-up. Northbound API rate limits govern the management plane – provisioning, configuration, reporting. They are a separate number from the platform’s signaling throughput, which is how many RADIUS or Diameter transactions per second the AAA server handles in live traffic. A vendor who answers a rate-limit question with a signaling throughput number has either misunderstood the question or is hoping you will. Ask for both, separately, in writing.
For our part, the Alepo AAA Server is engineered for carrier-grade availability 99.999% with active-active redundancy, and we size signaling throughput against an operator’s own peak authentication and accounting profile.
Can I test the API before signing?
Ask directly and ask early. The request is modest: sandbox or trial credentials plus the documentation, for a time-boxed technical evaluation by your own engineers.
Half a day is usually enough to learn what matters. Authenticate. Create a subscriber and attach a policy. Trigger a Change-of-Authorization (CoA) or disconnect. Retrieve accounting records for a session. Then deliberately break something send a malformed payload, request an object that does not exist and read what comes back.
That exercise answers questions no demo can: whether the documentation describes the platform that actually exists, and what error responses look like when you have to handle them. How a vendor handles the request is itself part of the answer – what they grant, how quickly, and on what terms. A long escalation, or an offer to demonstrate the API on a screen share instead, tells you something the RFP response did not.
REST/SOAP support: necessary but not sufficient
“REST and SOAP supported” describes transport. It tells you how requests reach the platform, not what you can ask it to do or how well the interface is documented.
The phrase “open API” deserves the same scrutiny, because it carries two meanings that are easy to conflate. One is an API that is openly documented and available to customers – a minimum. The other is an API that conforms to a published, industry-defined specification: for telecom, the TM Forum Open APIs that define standard resource models and operations across business support systems (BSS) and operations support systems (OSS). The second is what makes an integration built for one vendor’s platform substantially reusable against another’s. Ask which a vendor means, and which specific interfaces conform.
Protocol conformance on the signaling side is a separate question, worth asking in the same session. RADIUS is defined in RFC 2865 with accounting in RFC 2866, Diameter in RFC 6733, and TACACS+ device administration in RFC 8907. A platform can be rigorous about those and still carry a thin, undocumented northbound API; the two are built by different teams under different pressures.
For our part, the AAA Server exposes its northbound surface through REST and SOAP web services APIs with a published Swagger definition. Run the four questions against our documentation the same way you would against anyone else’s.
Adding these questions to your procurement checklist
The change is small: four rows added to a document you already maintain, asked of every shortlisted vendor identically. The table pairs the question most evaluations ask with the follow-up that produces a usable answer.
| Surface question | Deeper follow-up | Why it matters |
| “Do you have a REST or SOAP API?” | “Annotate our feature requirements list with the specific endpoint that exposes each item, and mark which are read-only.” | The feature sheet describes what the product does. The API reference describes what you can automate. The gap between them is your future manual work. |
| “Is there API documentation?” | “Send the OpenAPI or Swagger specification, the error-code reference, the authentication and credential-rotation guide, and the changelog.” | Documentation depth tracks how much the API is genuinely used. Thin or NDA-gated documentation is a signal about maturity, not about policy. |
| “Are there rate limits?” | “Document per-endpoint limits, whether they apply per credential or per tenant, burst versus sustained rates, throttling behavior, and whether they are contractual.” | An undocumented limit becomes a production incident during bulk migration, when you have the least room to absorb one. |
| “Can you integrate with [system]?” | “Give us sandbox credentials and documentation so our engineers can build a small integration during the evaluation.” | Only a working request confirms that the documentation matches the platform. A demo cannot. |
Ask while the decision still looks open, because that is when vendors answer specifically.
Then ask again at renewal. Apply the same four rows to the incumbent. Renewal paper is where unexamined assumptions survive longest, and API depth is a quiet contributor to lock-in even when the commercial terms look clean.
A vendor’s API is the part of the platform your team will interact with most and see demonstrated least. Four extra questions in the evaluation is a small price for finding out before signature rather than during the first integration sprint which kind of API you are buying.
Bring your integration engineers, not just your evaluation matrix
Book a working session and we will walk your team through the Alepo AAA Server API surface, the documentation, and the limits and talk through what your engineers can work against while the evaluation is still open.
Earlier in the evaluation? Download the AAA Server datasheet and put the architecture in front of your network and procurement teams first.
Frequently asked questions
Q1. What API questions does procurement typically forget to ask an AAA vendor?
Four: whether the API covers the full feature set rather than a subset of it, whether the documentation is usable, what rate limits apply, and whether the API can be tested before signature. Most evaluation matrices stop at confirming a REST or SOAP API exists the presence question rather than the depth question.
Q2. How do I evaluate API completeness in an AAA platform?
Send the vendor your feature requirements list and ask them to annotate each row with the endpoint that exposes it. Then check whether those endpoints support writes as well as reads, whether bulk operations exist, and whether configuration objects – realms, policies, NAS entries, attribute dictionaries are addressable through the API or only through the management interface.
Q3. Why does API documentation quality matter in vendor evaluation?
Because documentation depth is the cheapest available proxy for how much an API is actually used. Widely integrated APIs accumulate examples, error references, and changelogs, because gaps generate support tickets. Thin or NDA-gated documentation is a signal about API maturity regardless of what the roadmap claims.
Q4. What API rate limits should I ask about before signing?
The documented limit per endpoint, whether it applies per credential, per tenant, or per platform, burst versus sustained rates, and what the platform does when a limit is exceeded – a 429 Too Many Requests response with a Retry-After header is very different from a silent drop. Also ask whether sandbox and production limits differ.
Q5. Does REST/SOAP support guarantee real integration flexibility?
No. Protocol support describes how requests reach the platform, not what the API lets you do, how well it is documented, or whether it conforms to a published specification such as the TM Forum Open APIs. Completeness and documentation quality matter at least as much as transport.
Q6. Can I test a vendor’s API before signing?
Ask directly – sandbox credentials plus documentation for a time-boxed technical evaluation. Half a day of building against the API tells you whether the documentation matches reality and what error responses look like in practice.
Q7. How does API depth affect future integration flexibility?
A shallow API limits what can be automated later, which quietly recreates lock-in even with a vendor that markets a genuinely open API. Every capability exposed only through the management interface becomes manual work or a professional-services engagement – a switching cost like any other.
