API and MCP Management Queries Answered!

In the DigitalAPI External Developer Portal, the partner does it themselves. They sign up, create an app, and subscribe that app to a plan on the API they want. If the plan needs a human to say yes, the request lands with your approver.

On approval, the key is issued and the portal shows it once, inside the partner's own account under My Apps. If they lose it, they regenerate it. You see the request, the decision and the app in your admin view. You never see the secret, and you never email anything.

Yes. DigitalAPI lets you build the sign-up form: company, country, what they are building, rough volume, whatever helps you work out who they are. The answers decide where they land. A partner in one market gets routed to that market's Organisation, catalog and approver, so one portal covers several regions without you running separate copies.

Yes. DigitalAPI treats sandbox and production as separate environments on the same API, each with its own plan and its own key. A common setup: 90 days of sandbox, approved automatically, then a production Subscription that needs sign-off and a contract. Moving from sandbox to production is an approval, not a new onboarding.

Yes. The DigitalAPI External Developer Portal puts the catalog, the docs, the test console and the Request access button on one page. A partner reads the spec, pokes at the API, and asks for access right there. You choose which APIs anonymous visitors can see and which only appear after sign-in.

Yes. In DigitalAPI, terms acceptance is a step in sign-up or subscription, and the click is stored with a timestamp against the partner's account. Change the terms and you can require everyone to accept again. Legal can export the lot.

Only their slice. The DigitalAPI External Developer Portal shows a partner the APIs published to their Organisation, their apps and keys under My Apps, their Subscriptions and how much quota they have burned, and their own call stats. Admin screens, other partners' APIs and billing settings stay hidden unless you want them shown.

Yes, in two places. DigitalAPI has sign-up approval, which decides who gets into the portal at all (handy for partner-only marketplaces that are not open to the public), and Subscription approval, which decides who can call a given API on a given plan. Make either automatic for low-risk tiers and manual for production or paid ones.

Yes. A DigitalAPI access request can raise a ServiceNow ticket through the built-in integration, or a ticket anywhere else via webhooks. Approve it in that tool and the Subscription goes live in the portal and the partner gets their key. Your approvers never leave the tool they already live in, and the trail exists on both sides.

Yes. A DigitalAPI approval step can call out to a KYC provider or an e-signature service and hold the request until the answer comes back. The signed contract or KYC result is attached to the partner's Organisation. For regulated teams this is the difference between a year of manual onboarding and a couple of weeks.

Yes. DigitalAPI supports a four-eyes rule: a technical approver and a business approver on the same request, and nothing is issued until both say yes. Approvers are set per API product, so whoever owns an API decides who approves access to it.

In DigitalAPI, the approver has to give a reason, and the partner sees it. That request is closed. If the partner fixes something and applies again, it is a brand-new request with its own workflow run, so every decision has its own record. Nothing gets quietly reopened.

Yes. In DigitalAPI, each partner type is an Organisation, and each Organisation has its own view of the catalog. Resellers, integration partners and direct customers can all sit on the same portal and see three different sets of APIs. Nobody in one Organisation can peek into another.

Yes. A DigitalAPI Organisation can hold as many teams as you like, each with its own members, apps and keys. Quotas and analytics roll up to the Organisation; each team looks after its own apps.

Yes. In DigitalAPI an API that is imported but not published is invisible to every consumer. A published API can be shown to specific Organisations only. Internal-only APIs stay in the catalog for your own teams and never show up for partners.

It is up to you. By default your DigitalAPI admin creates the Organisation and invites the partner's first person, who invites the rest. If you would rather let partners self-create, you can lock it to approved email domains, so two people at the same partner cannot each spin up their own organisation.

Yes. In DigitalAPI an API product is a bundle of one or more APIs with Plans attached. The partner subscribes to the product. If your clinical and appointments APIs are sold together, that is one product and one Subscription. The same API can live in several products with different Plans.

Both work, and there is nothing to install. DigitalAPI signs your own people and admins in through SAML or OIDC (Okta, Azure AD, whatever you run). Partners can register with the portal's own login, or come through your IdP if you already give partners identities there. Roles can be driven off IdP groups.

Each app gets its own. In DigitalAPI a partner with three integrations has three apps and three credentials, each with its own quota and its own stats. Shared credentials are an audit headache because you cannot tell who did what; per-app credentials fix that by design.

Yes. DigitalAPI roles are scoped to the Organisation or domain an admin owns. A regional admin approves requests, manages partners and reads reports for their region only. A global admin sets rules that cascade everywhere; regional admins can tighten them but not loosen them.

Yes, we check tokens issued by your authorisation server. The partner's app gets a client ID and secret, hits your token endpoint, and sends the token on every call. The portal's test console can fetch that token for them, so they can try the API before writing a line of code.

No. DigitalAPI imports existing credentials and maps them to partner apps, so partners keep calling exactly as they do today and you get visibility and control straight away. Then you move them to rotated keys or OAuth on your own timetable, one Organisation at a time, with old and new credentials both valid during the switch.

Nobody. DigitalAPI shows the secret once to the partner when it is created and stores it hashed. Admins see the key ID, the app, the owner and the status, never the secret. Lost it? The partner regenerates it.

Yes. In the DigitalAPI External Developer Portal a partner goes to My Apps and generates a new key, and the old one keeps working for a grace period you set (say 7 days) so their integration swaps over without downtime. You can also force it: set a maximum key age per Plan and the Gateway stops honouring old keys on the day.

Revoke the Subscription or the app in the DigitalAPI admin console. The Gateway rejects their very next call. The revocation is logged with who did it and when. You can pull one app, one Subscription, or a whole Organisation in one go.

Yes. For cloud backends, DigitalAPI reaches your gateway and upstream services with short-lived, role-based credentials, so no long-lived access key sits anywhere. Partners can be given short-lived tokens instead of static keys too, where your policy calls for it.

Yes. In DigitalAPI maximum key age is a Plan setting. Partners get warned by email and in the portal before expiry, and the DigitalAPI Gateway rejects anything past its date. When your security team shortens the window again next year, it is a settings change, not a project.

Yes. A DigitalAPI recertification campaign lists every live Subscription on an API and asks its owner to confirm or revoke each one. Anything left unconfirmed at the deadline can be suspended automatically. The finished campaign exports as evidence for your auditors, which is the thing ISO 27001 and SOC 2 reviews keep asking for.

Yes. My Apps in the DigitalAPI External Developer Portal shows a partner their calls, errors and quota used per app, by day. Because every request is metered, the number they see is the number you bill. Both sides read the same figure, which is why the monthly "we didn't send that many" emails stop.

Yes. The DigitalAPI admin console filters Subscriptions by Organisation, user, API product, Plan and status. "What does this partner have access to" and "who has access to this API" are both one screen, and both export.

In DigitalAPI every credential has an owner, a creation date, an approver, an expiry and a revocation record. Recertification adds a periodic "still needed?" on top. Between them they answer the three questions every access review asks: who has access, who approved it, and when was it last checked.

Yes. DigitalAPI pushes Subscription events (created, approved, expiring, expired, revoked) and usage summaries out through webhooks to Salesforce or whatever CRM you use. An account manager sees when a partner's access runs out and how much they are using without opening the portal. Sandbox access and promotion to a paid licence show up as stages on the account.

Yes. The DigitalAPI audit log captures every sign-up, approval, rejection, credential event and admin change, and streams to Splunk, Datadog, Elasticsearch and the usual suspects. The data is yours. DigitalAPI keeps request metadata only (timestamp, status, latency) and never stores request or response bodies.

Because it only knows about that one gateway. Most enterprises run two or more plus a pile of internal services, and partners want one place to find and request all of it. The DigitalAPI External Developer Portal sits above the gateways and gives you one catalog, one approval flow and one credential model, while each gateway keeps doing the traffic work it does today.

Yes. Everything in DigitalAPI (APIs, products, Plans, Organisations, roles, approval rules) is reachable through the management API, so you can keep it in version-controlled config and apply it through CI. Prefer the UI? Same state, exportable any time. The catalog is never trapped in one system.

Days for a hosted DigitalAPI environment. Connecting a gateway, a spec source and SSO is configuration, usually done inside the first two weeks. Most teams run a four-week pilot with two or three partner Organisations before opening the doors wider.

No. DigitalAPI gateway connections are read-only, used for discovery and metering. Live traffic still goes partner to your gateway to your backend, same as now. Your IdP stays the identity source. DigitalAPI connects to the major gateways and spec sources out of the box, so the catalog is imported rather than retyped.

A long way. In the DigitalAPI External Developer Portal, pages, forms, branding, navigation and content are drag-and-drop, no code. Custom workflows, external checks and integrations run on webhooks and the management API. Professional services is for bespoke hooks into internal systems, not for day-to-day changes.

Count three things in your current process: how many people touch each partner credential, how many live credentials have no rotation date, and how many days from a partner asking to their first successful call.

On the calls behind this page the usual answers were three or more touches per key, every credential unrotated, and weeks to months to first call. With the DigitalAPI External Developer Portal the outcome is zero touches, every key dated, and first call in the same week. The engineers who used to make keys by hand go back to building product.

Publish APIs by choice, not by default. In DigitalAPI, you import your APIs and then publish only the ones you choose, to the audiences you choose. An imported-but-unpublished API is invisible to consumers, so what you expose stays a deliberate decision rather than a free-for-all.

Yes, DigitalAPI treats sandbox and production as separate environments on the same API. You can publish a sandbox, including mocked services, for partners to build and certify against, then promote them to production as a controlled step.

Yes, you choose exactly which APIs and versions go into the catalog and who sees them, so you are never forced to publish your whole backend to get one API in front of partners.

Yes, DigitalAPI lets you publish some APIs openly, others behind sign-in and an API key or plan, and others only to specific partner organisations. A public catalog, a monetized tier and a private subsidiary-only set can all live on the same portal with different rules.

Yes, in DigitalAPI, an API product is a bundle of one or more APIs with plans attached, so you publish and grant access to the product. You expose an accounts-payable product or a payments product, not one giant surface.

One place where a developer finds the API, reads the docs, tries it, and asks for access. The DigitalAPI External Developer Portal brings the catalog, documentation, a test console, and the request flow together, so developers do not hunt across several sites for one integration.

Yes, DigitalAPI gives you one unified catalog across the gateways and systems you run, so a partner comes through one front door rather than a different portal per product or team.

Yes, in the DigitalAPI External Developer Portal, pages, branding, navigation, and content are yours to set, no code, so the portal reads as your product, not ours.

Yes, Developers can explore a published API and make test calls from the portal against a sandbox environment before they request production access. The sandbox runs through the gateway, so the behaviour they test is the behaviour they get.

Generate it from the spec. DigitalAPI builds the portal's documentation from your API definitions, so the docs reflect what the API actually does instead of drifting in a separate wiki.

Yes, A published API sits in a searchable catalog with its methods described. That same description lets your own agents discover which method to call through the DigitalAPI MCP Gateway, so discovery works for people and for agents.

Yes, DigitalAPI connects to spec sources such as SwaggerHub, Postman, and your repos, and pulls the schema and docs in, so you are not copy-pasting definitions by hand to publish.

Yes, Alongside the generated API docs, you can add your own pages, guides, and branding in the DigitalAPI External Developer Portal, so onboarding content and reference docs live together.

Self-serve, with your rules. The developer signs up, subscribes an app to a plan, and gets a credential once the request is approved. You decide which tiers are automatic and which need a human, so onboarding goes from weeks to the same week.

Yes. Sign-up and subscription both support an approval step, and production access can require sign-off while a sandbox tier stays automatic. Rejections carry a reason, and every decision is recorded.

Yes. DigitalAPI works with your IdP through SAML or OIDC and checks tokens from your own OAuth server, so partners authenticate against the identity system you already run rather than a separate store.

Yes. In DigitalAPI, each app gets its own credential with its own usage and stats, so you can always tell which application made which calls, rather than several partners sharing one key.

Keep versions side by side. DigitalAPI lets a published API run more than one version, so existing partners stay on the one they built against while new ones move to the latest, and you deprecate on your own schedule.

Publish both from the same definition and run them through your gateway, so what a partner certifies in the sandbox matches production. Promotion from sandbox to production is a controlled step, not a re-integration.

Yes. Partners subscribe to the APIs they use, so when you publish a new version, you can let the subscribers know rather than hoping they spot it.

Every API in DigitalAPI has an owner, and recertification periodically asks that owner to confirm what is still live. So a published API does not become something partners depend on that no one maintains.

In DigitalAPI, publishing is a permission, scoped by organisation or domain, so only the people you authorize can push an API into the catalog, and a regional admin manages only their region.

Mostly through control. Putting an API behind the gateway with keys, auth, and rate limits means public endpoints are not a free-for-all, and you decide who gets efficient, higher-volume access through a proper plan instead of scraping.

It gives you the controls a regulated program leans on: scoped access, approvals, an owner and expiry on every credential, and an audit log streamed to your own tools, so you can show who accessed what and when. The compliance posture of the data itself stays with your systems, where the traffic runs.

Yes. DigitalAPI organises the catalog by organisation and team, so a US team and an Asia team can each own and manage their own published APIs within one platform and one set of rules.

The part that matters to most teams: your APIs and live traffic do not move. DigitalAPI's gateway connections are read-only, used for discovery and metering, so partner traffic keeps flowing through your own gateway and backend. How the platform itself is deployed is flexible and set with your team.

Give the agent a governed path instead of wiring it straight in. The DigitalAPI MCP Gateway exposes your existing APIs to your own agents through a controlled runtime, so an agent built in AWS, Azure, or anywhere else can consume the APIs you already run, and only the ones you allow.

Yes. Through the DigitalAPI MCP Gateway, an agent connects to your application over MCP and performs the actions you have exposed as tools, so you can hand it a task and let it carry it out against the real system.

Hand APIs to agents as a described tool, not a raw endpoint. DigitalAPI turns your API into an MCP tool with its methods and inputs described, so the agent knows what the API does and how to call it without you spelling out each step.

Convert it, do not rebuild it. DigitalAPI MCP Studio turns an existing API into an MCP server without code, so your agents can discover and call it as a tool using the API you already have.

That is the point of exposing your APIs as MCP tools. Instead of hand-coding which method to call for each task, DigitalAPI gives the agent the tools and their descriptions so it can pick the right method for the instruction it is given. The workflow stops being static.

No. The tedious part, taking a handful of API calls and wiring them into a tool, is what the platform does for you. Point DigitalAPI MCP Studio at your API and it generates the MCP tools, so you are not hand-building each one.

Yes. DigitalAPI MCP Studio can take your existing API definitions, including specs you already keep in Postman or a spec source, and turn them into MCP tools, so the agent learns the methods from what you already have.

Put the agent's traffic through a gateway that enforces rules. The DigitalAPI MCP Gateway controls which tools and APIs each agent or group can reach, and to what level, so an agent only touches what you have allowed.

Yes. The DigitalAPI MCP Gateway runs the agent-to-API layer within your control, so the data and access stay scoped to your organisation rather than leaking into a shared, generic system.

Yes. DigitalAPI governs agent access the same disciplined way it governs partner access, so you can scope what an agent can do by role, and apply finer attribute or policy-based rules for machine-to-machine access where compliance, for example around PII, calls for it.

Yes. You can expose a tool to a small set of agents or teams first, run it in a controlled way, and revoke a particular access cleanly before any wider rollout, so you are not forced into a big-bang launch.

Give agents scoped, managed credentials, the same way you would a partner. The DigitalAPI MCP Gateway handles auth for agent traffic, so each agent gets only the access it needs, and you can revoke it cleanly.

No. The DigitalAPI MCP Gateway applies rate limiting and enforcement at the gateway, so you do not have to build those checks into each API, which matters when one agent tool fans out to many backend APIs.

Yes. DigitalAPI works with your own IAM or identity provider, including custom ones, so agent access runs off the identity system you already trust rather than a separate one.

Log it at the gateway. The DigitalAPI MCP Gateway records the calls your agents make, so you have a clear trail of which agent reached which API and when, which matters once agents are acting on real data.

Treat each exposed API and tool as owned, not orphaned. DigitalAPI tracks who owns each API and tool and handles versioning, so what your agents depend on does not become something no one maintains.

Route all agent and API access through the same gate. With the DigitalAPI MCP Gateway, every agent action goes through one secured entry point and is logged, so nobody bypasses the checks and every call is accounted for.

Reach the data through governed APIs, not a raw dump. DigitalAPI lets an agent get your data by calling your APIs through the MCP Gateway, so your proprietary information stays behind your own controls instead of going into a shared, public model.

Meter it at the gateway. Because agent traffic goes through the DigitalAPI MCP Gateway, every call is counted, so you can see how much each agent is using and keep it within limits instead of guessing.

Expose the system's actions as tools. DigitalAPI MCP Studio turns the relevant Oracle EBS APIs into MCP tools, so an agent can place a procurement request, create a sales order, or run other day-to-day tasks against the real system, within the access you allow.