canonical: https://jentic.com/apis/nexmo.com/vonage-application-v2

# Nexmo Application API

The Vonage Application API V2 (application.v2) is the current management surface for Vonage Applications - the container that bundles webhook URLs, signing keys, and capability flags across Voice, Messages, RTC, and Verify. It is backwards compatible with v1 applications. The 5 endpoints provide create, list, retrieve, update, and delete operations against /v2/applications and return the public key plus capability webhooks needed to drive Vonage's product APIs.

## For AI agents

Provision and manage Vonage v2 applications - the multi-capability container that binds voice, messages, and verify webhooks to a Vonage account.

## Scope

Does not place voice calls, send messages, provision numbers, or run verification - use for Vonage v2 application lifecycle and capability webhook configuration only.

## Capabilities

- Create a Vonage v2 application bundling voice, messages, RTC, and verify capability webhooks in one call
- List paginated v2 applications scoped to the authenticated Vonage account
- Update an application's per-capability webhooks and signed webhook secret without rotating its keys
- Retrieve an application's public key and capability set before binding a virtual number
- Delete an unused application after its capabilities have been moved off
- Manage the private/public key pair that signs JWTs for Voice and Conversation APIs

## Use cases

### Provision a multi-channel application

Building a customer service experience that combines voice IVR and WhatsApp messaging requires a single Vonage v2 application with both voice and messages capabilities configured. POST / accepts a capabilities object that declares answer_url, event_url, inbound_url, and status_url per channel. Once created, the same application_id is used to mint JWTs for both the Voice API and the Messages API.

Example prompt: POST / with name 'support-bot', voice capability webhooks, and messages capability webhooks for the support tenant.

### Rotate webhook URLs after backend migration

When a backend handler is moved to a new domain, every Vonage v2 application needs its webhook URLs updated. PUT /{id} replaces the capabilities block, preserving the application's signing key and number bindings. A migration script can iterate via GET / and PUT each application in sequence, finishing in minutes.

Example prompt: For each application_id from GET /, PUT /{id} with capabilities.voice.webhooks.answer_url set to the new domain.

### Audit application inventory across an account

Compliance reviews require a periodic export of every active application, its enabled capabilities, and its webhook URLs. GET / paginates through the full list. A weekly cron can write the inventory to long-term storage for review against the deployment registry. Roughly half a day of work.

Example prompt: Iterate GET / with page and page_size until exhausted and write each id, name, and capability set to an inventory file.

### Agent-driven tenant onboarding

An onboarding agent provisioning a new tenant searches Jentic for 'create a vonage application', loads the POST / schema, and executes with the tenant's webhook URLs and a generated key pair. Jentic's vault holds the API key and secret; the agent never handles the credentials directly.

Example prompt: Search Jentic for 'create a vonage application', load the schema, and POST / with the new tenant's name and capability webhooks.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | / | List available applications |
| POST | / | Create an application |
| GET | /{id} | Get an application |
| PUT | /{id} | Update an application |
| DELETE | /{id} | Delete an application |

## Key resources

- **Applications** — Create, list, retrieve, update, and delete Vonage v2 applications and their capability webhooks.

## Why Jentic

- **Setup:** Wiring the Vonage Application API by hand means setting up HTTP Basic auth with your API key and secret, pointing at the v2/applications host, and managing the application lifecycle and capability webhooks yourself. Through Jentic you install once, import the Application API from the API Directory, store the key and secret once, and your agent calls it.
- **Permission scoping:** This API puts the application id in the URL path (/{id}), so a rule can pin your agent to one application: it can read and update that application and nothing else. You choose the operations it may call, so application creation and deletion are not included unless you add them.
- **Credential handling:** Your Vonage API key and secret are stored once, encrypted, by your own Jentic One instance and injected as the Basic auth header at execution time. They never enter the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'list Vonage applications' or 'update an application's webhooks', and Jentic returns the matching Application API operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Vonage Voice API** — Vonage's voice calling API tied to Vonage applications.
- **Vonage Messages API** — Vonage's omnichannel messaging API for SMS, MMS, WhatsApp, Viber, and Facebook Messenger.
- **Vonage Numbers API** — Vonage's virtual phone number provisioning API.
- **Twilio Accounts API** — Twilio's account and subaccount management API.
- **Plivo API** — Plivo's SMS, voice, and account management platform.

## FAQ

### What authentication does the Vonage Application API V2 use?

It uses HTTP Basic authentication with the Vonage API key and API secret. Jentic stores both in the encrypted Jentic One instance and injects them per call so the agent never holds the raw secret.

### Is the Vonage Application API V2 backwards compatible with v1?

Yes. Vonage states that applications created with v1 can also be managed via v2. The base path is /v2/applications and all v1 application_ids continue to resolve under v2 endpoints.

### What are the rate limits for the Vonage Application API V2?

Application management is a control-plane API. Vonage does not publish a hard per-second cap in the spec; treat GET / pagination as eventually consistent and avoid hammering the endpoint in tight loops.

### How do I create a v2 application through Jentic with the Vonage Application API V2?

Run pip install jentic, search Jentic for 'create a vonage application', load the POST / schema, and execute with the capabilities object. Credentials are pulled from the vault at call time.

### Can I configure messages and voice capabilities on the same application with the Vonage Application API V2?

Yes. POST / and PUT /{id} accept a capabilities object with separate sub-objects for voice, messages, rtc, and verify, each with its own webhook URLs. A single application_id can carry several capabilities at once.

### Does the Vonage Application API V2 return a private key on application creation?

Yes. POST / returns a keys.private_key in the response body that you must store immediately - Vonage does not retain it. The matching public_key is queryable via GET /{id} for verification.

### Can I limit what my agent is allowed to do with the Vonage Application API V2?

Yes. Because you run Jentic One yourself, your own rules decide which of the five operations your agent may call and which Vonage credentials it may use. Since the application id sits in the URL path at /{id}, you can pin the agent to a single application so it only retrieves (GET /{id}) and updates (PUT /{id}) that one, while leaving out list, create, and delete unless you choose to allow them. Your Vonage API key and secret stay stored in your own instance and are attached to each call, so the agent never sees the raw secret.