Live Caller ID Lookup: is there any way to check onboarding status after approval?

We have a Live Caller ID Lookup deployment that has been blocked for weeks, and the core difficulty is not technical. It is that we cannot find out anything about the state of our onboarding submission.

Here is where we stand. We submitted the onboarding form and our configuration was approved on 8 August. That approval email is the only communication we have ever received about this feature. Our service is deployed and verified: the OHTTP gateway negotiates HTTP/2, serves a valid key configuration, the issuer directory returns 200 and Apple polls it continuously, the DNS TXT record is in place, and the validation identity is in our corpus. Development builds work end to end and display caller names correctly on incoming calls.

App Store builds do not. Every authenticated request fails on the device in roughly 47 ms, before anything leaves the phone:

ciphermld(CipherML) requestData(byKeywords:shardIds:clientConfig:) threw NSURLErrorDomain Code=-1009 _NSURLErrorPrivacyProxyFailureKey = true nw_endpoint_proxy_handler_should_use_proxy: "Proxies not present, but required to fail closed"

The network path is healthy in the same moment, and other processes on the device do receive proxy configuration. Only our extension's bundle identifier never does. We reproduced this on Wi-Fi and on cellular, and after a device restart.

We have since learned, from a maintainer replying to an issue we opened on the pir-service-example repository, that "approved" in the CloudKit console is not the same thing as "successfully onboarded", and that we are still in the first state. That explains the behavior completely. What we cannot explain is how a provider is supposed to discover this. There is no status field in the console, no notification when the state changes, and nothing in the onboarding documentation that mentions a second stage exists.

We wrote to Apple several times over these weeks. We were told more than once that an internal team would look into it, and we never received a reply. Apple Support told other providers in the same situation that this is a technical matter beyond their scope.

Looking through the pir-service-example issues, this pattern is common. One provider reported waiting three months without a response. Another reported that form to production took almost four months. Another only discovered the feature had been enabled by noticing traffic arriving at their own server.

My questions:

  1. Is there any supported way to check the onboarding state of a submitted configuration, or to ask about one that appears stuck? If not, is anything planned?

  2. Is the transition from "approved" to "successfully onboarded" expected to be automatic, and roughly how long should it take?

  3. For anyone who has been through this: did you eventually get a notification, or did you find out by watching your own server logs?

We are not asking for our submission to be prioritized. We would simply like to know whether we are waiting on something or whether something needs to be resubmitted, and right now there is no way to tell the difference. Our paying subscribers cannot use the feature, and we have not been able to give them an accurate answer either.

Thank you.

that "approved" in the CloudKit console is not the same thing as "successfully onboarded"

Right. That matches my understanding:

  • The Approved state indicates that your request has been approved but isn’t yet configured.
  • The Successfully Onboarded state indicates that everything is ready to go.

You included your request UUID in your other thread (693155e2-b8ba-4b47-9b6c-64fd97677386) and from that I was able to confirm that you’re in the first state.

What we cannot explain is how a provider is supposed to discover this.

Good question. I’m not actually sure what the developer side of this looks like, so I’m going to research that and get back to you.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thank you for confirming this, and for checking the request UUID. That answers the question we had been unable to resolve on our own: we are in Approved, not Successfully Onboarded.

Our request was approved three weeks ago and has not moved since. Meanwhile the app is live and the extension ships in it, so the situation on our side is:

| Measured today | Devices | | Active paying subscribers | 357 | | Devices that ever reached our PIR service | 83 | | Devices able to query today | 18 |

Those 18 are not evidence that anything works. In the related GitHub thread, karulont explained that a device on a full-tunnel VPN currently skips OHTTP and connects directly, that this is a bug, and that it will be fixed in a future OS release. We reproduced that exactly, as an A/B on one device minutes apart: VPN on, the query reaches us and the caller name appears; VPN off, nothing reaches us at all. So every working user we have is working by accident, and when that fix ships the number becomes zero.

The useful part of that test is that it proves our deployment is correct end to end. When a device does reach us, Privacy Pass issuance, configuration, evaluation keys and the PIR query all work and return the right answer. There is nothing left for us to fix or to test.

Two requests, if you are able to help with either:

  1. Is there any way to expedite the move from Approved to Successfully Onboarded, or to find out what it is waiting on? We have no visibility into it and no contact who can tell us.
  2. Whatever you learn about how a provider is meant to discover this state, we would be glad to see documented. We spent months assuming the fault was ours.

We are not asking for the OHTTP bug to be left in place. We are asking for the correct path to be available before the fix removes the accidental one, because at that point subscribers who have paid for this feature since launch will have no way to use it at all.

Live Caller ID Lookup: is there any way to check onboarding status after approval?
 
 
Q