Quick answer: E911 works when two things come together on the same call: the carrier routes the emergency call to the right PSAP, and a dispatchable address record is attached to the calling number so responders know where to go. On Devotel Orbit the routing obligation sits with the carrier; the address lifecycle is a tenant-operated workflow: register the civic address on the number (PUT /numbers/:id/emergency-address), run the local structural check, ingest the carrier or PSAP confirmation, and reconfirm after every edit. The address reaches dispatchable, the only status a PSAP can act on, only when that confirmation is on record. Below is the register process end to end, the split of responsibilities a procurement review should force into writing, and where the feature stops.
The E911 buyer guide covers the evaluation questions. This post is the operational half: how a tenant actually registers, validates, and keeps a dispatchable address current, using the same endpoints the emergency-address reference documents.
The four-state lifecycle on each number
Every E911 address moves through the same four states, and every state transition is an API call you can also make from the number's detail page in the dashboard:
- `registered` —
PUT /numbers/:id/emergency-addresswrites the caller name, street, city, region, postal code, and country code. An update replaces the prior address and resets the lifecycle, so registrations are never cumulative. - `valid` —
POST .../emergency-address/verifyruns a local structural pre-check: required civic fields present, postal-code shape strict for the two NANP countries. It is deliberately local; it never calls a provider address API and costs nothing, andvalidis not a usable state, only a passed gate. - `dispatchable` —
POST .../emergency-address/psap-confirmationrecords the carrier or PSAP verdict that arrives out of band, withconfirmed: true. This is the only status that means responders can act on the address. - `invalid` — the same confirmation endpoint with
confirmed: falseand a rejection reason. An invalid address is worse than none in a review, because it reads as covered until someone checks the status field.
The failure mode to design against is the reset: any edit to the address returns the record to registered, and the states reached before the edit no longer apply. A tenant that treats registration as permanent has built a stale-address pipeline, and a stale address mis-routes the same way no address does.
Where the carrier's job ends and yours begins
Procurement screeners ask "do you support E911?" and get a yes that hides the split. The division of labor is fixed, and each side should be able to state its half in writing:
- Routing is the carrier's obligation. In the U.S., the FCC's emergency-calling rules attach to the voice carrier of record for the number: the originating carrier on platform numbers, the downstream carrier on bring-your-own numbers. Kari's Law (direct-dial 911 with no access code) and RAY BAUM's Act (a dispatchable location per caller) define what correct routing means, and the carrier answers for both. This is a carrier property, not a platform toggle.
- The address record is the tenant's obligation. No carrier can guess where your people sit. Registering the civic address, validating its shape, and getting the carrier's confirmation on file is operational work your team does; Orbit's part is giving you the API, the dashboard surface, and the visible lifecycle states to do it with.
- The platform declares its outbound posture. Devotel Orbit's posture is block-and-disclaim, described in the buyer guide linked above: the address is kept as a regulatory record with an explicit dispatchability status, and the declaration is in writing rather than implied by a marketing bullet. Your review should insist on that declaration from every vendor on the shortlist.
When a review forces this split onto one page, the "do you support E911" yes turns into an answer you can audit: routing obligations documented by the carrier, address workflow operated by the tenant, platform posture stated by the vendor.
Worked example: from form to dispatchable
The same three calls work from the dashboard (Numbers → number detail → Emergency address) or straight from the API:
- Write the address.
`` PUT /numbers/:id/emergency-address { "callerName": "HQ front desk", "street": "1408 Elm Street", "city": "Tulsa", "region": "OK", "postalCode": "74120", "country": "US" } ``
- Run the structural check.
`` POST /numbers/:id/emergency-address/verify → { "status": "valid" } ``
- Record the carrier's verdict when it returns.
`` POST /numbers/:id/emergency-address/psap-confirmation { "confirmed": true } → { "status": "dispatchable" } ``
From dispatchable onward, the only remaining work is discipline: re-run the sequence whenever the address moves, and schedule any live test call through the PSAP's coordinated test window rather than dialing 911 to check. A response of invalid on step three carries the carrier's rejection reason, and fixing the cited field is the only loop back.
A U.S. boundary, stated plainly
The emergency-address surface is deliberately shaped like a U.S. obligation. The local verification step enforces postal-code shape only for the NANP countries, and the dispatchable status tracks the carrier or PSAP confirmation loop that U.S. regulation defines. Treat the scope as U.S.-only. If your numbers or your callers sit outside the U.S., do not read a dispatchable status as emergency-calling coverage there. The honest answer for those deployments is that emergency dialing is handled by the local carrier arrangement, or not through the platform at all.
Frequently asked questions
How often should the address be reconfirmed?
After every edit, and whenever the physical location changes: office moves, new floors, relocated staff. A scheduled annual re-run of step two and three is the cheap way to catch drift before a review does.
Can subaccounts inside one organization register their own addresses?
Yes, with isolation. The lifecycle is per-number, and organization ownership gates it: a sibling subaccount in the same workspace can neither read nor mutate another subaccount's dispatchable location.
What does a 422 on the verify call mean?
The structural check failed - at least one required civic field is missing or the postal code does not match the country shape. The response names the field; fix it and re-run before attempting confirmation.
Does a dispatchable address change what happens on an emergency call?
Routing itself remains the carrier's job in every state. What dispatchable changes is the location data the carrier has on file for the number, which is what a PSAP uses to send responders to the right place.