Your Own Domain

The address you give a partner is the most permanent thing you give them. It ends up in their configuration, their deployment scripts and their change-control records, and getting it back later means asking every one of them to do work.

So it should be an address you own. Not ours.

What it changes

By default an API is published on the gateway’s own host, which is fine for an evaluation and fine for internal consumers. For anything you hand to a partner, put it on a hostname you control — api.yourcompany.com, or whatever fits your estate.

When you do, the host is yours end to end:

	On the gateway host	On your own domain
Base URL	alpha.gateway.apiway.net/{api}-v1	https://api.yourcompany.com
Path prefix	The API’s prefix	None — your host is the root
OpenID discovery	On the gateway host	https://api.yourcompany.com/.well-known/openid-configuration
Token endpoint	On the gateway host	On your domain

That last pair matters more than it looks. A partner’s OAuth client is configured with a discovery URL, so if that points at us, your identity surface is ours too. On your own domain the whole exchange — discovery, token, the calls themselves — happens at an address you own.

How you set it

It is a field on the API, not a separate system:

curl -X PATCH https://core.api.apiway.net/v1/apis/{id} \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "customDomains": "api.yourcompany.com" }'

The hostname is carried into the deployment package and reaches the gateway on the next deployment, the same path every other change takes. Nothing about your contract, your subscriptions or your consumers’ credentials changes because the host did.

Two steps, and one of them is ours today

Setting the field is yours. Making the hostname resolve and serve HTTPS involves us: you point a CNAME at the gateway, and we enable the hostname and its certificate on the instance serving you. Ask for it when you are setting up the environment your partners will use, and it is done before they integrate rather than after.

We are not going to pretend this is self-service. It is the one part of publishing an API here that still involves a person.

Decide it before partners integrate

Moving a partner from one host to another is the one change this platform cannot make invisible. Everything else about going live is designed so your consumers never notice — the stand-in becomes your real service underneath a layer built not to care. The host is different, because the host is the thing they wrote down.

So the sequence that avoids the only unavoidable break:

1. Decide the hostname before you invite anybody.
2. Put it on the environment that will serve them in the end, not a development one.
3. Hand out that URL and those credentials.
4. Build and release underneath it as often as you like.

What it means if you leave

This is the part worth being blunt about, because it is usually where a platform quietly keeps you.

If your partners integrated against our hostname, that hostname is ours, and moving away means every partner re-points and re-credentials. That is a genuine cost and it is a genuine reason to hesitate.

If they integrated against yours, there is nothing to move. The domain is yours, the DNS is yours, and where it points is a decision you make. Combined with the fact that your contracts, history and subscriptions are readable at any time, what you would be leaving with is the whole thing, at the address your partners already hold.

We would rather you stayed because the platform is worth it.

See also: From Mock to Real · Environments · Exit and Continuous Audit