Live Caller ID Lookup shows “Access Denied” with wrong config URL

[Alan-Cheng]

Hello Apple team,

We have followed the process to apply for Live Caller ID Lookup and received approval with the following response:

Thank you for your interest in Live Caller ID Lookup.
Apple’s OHTTP relay has been configured to talk to your OHTTP gateway.
Now Live Caller ID Lookup should work for your application extension when distributed through App Store.

However, when enabling the caller ID feature in our app, we encounter the following error:

Unable to query status due to errors:
server error

<TITLE>Access Denied</TITLE>

Access Denied

The error message shows the URL:
http://example.com/config

This is clearly not the OHTTP gateway URL we provided during the application process.

Current situation:
• The app is available on TestFlight and has passed App Store review.
• Apple previously confirmed that the query worked during the approval process.
• But in practice, the app fails to query and returns “Access Denied.”

We would like to ask:
1. Why does the actual query point to http://example.com/config instead of our configured OHTTP gateway URL?
2. Is there any additional configuration required on our side, or is the Apple-side configuration not fully in effect yet?

Thank you for your support!

[karulont]

Please use feedback assistant to file a report with sysdiagnose and more details like the OHTTP gateway URL, service URL and the full error you are seeing.

Anyhow on first glance this looks like there is some misconfiguration somewhere.
It may be a problem with your OHTTP gateway configuration. Your OHTTP gateway should forward to your service, not to "example.com".

[Alan-Cheng]

Thanks for the clarification!
Just to confirm — isn’t the OHTTP gateway supposed to forward the request to the target URL that’s encapsulated inside the encrypted HTTP request (i.e., determined by the client)?
Or do you mean that the OHTTP gateway should instead be configured to automatically forward all incoming requests to our PIR service endpoint?

Also, just to clarify, I’ve currently released a TestFlight build for testing (it hasn’t been published to the App Store yet).
Would requests from this TestFlight version also go through Apple’s OHTTP relay, or does that only apply to apps distributed via the App Store?

[karulont]

Yes, you are right, the OHTTP gateway is supposed to decapsulate the request and then forward it. While the gateway can do some things like only allow forwarding to specific endpoint or rewrite the target url, it is not required do so.

Anyway, can you provide a hint to which gateway, service are we talking about, so I could take a look myself?

When distributed through TestFlight it should use Apple's OHTTP relay.

[Alan-Cheng]

Thanks! Here’s the gateway we’re using:
https://osbstage.twmsolution.com/ohttp/ottp-metadata

And this is the PIR service endpoint:
https://osbstage.twmsolution.com/pir

Let me know if you need any additional details.

[karulont]

We found a configuration issue where Apple's OHTTP relay limits the response size and returns a HTTP 502 error code.
However, that does not explain where the "Access denied" HTML page comes from.

[Alan-Cheng]

Thanks for the clarification. It seems the 502 is due to Apple’s relay and not our service. For the Access Denied page, could you advise if there’s anything we should check or adjust on our side?

Thanks!

[karulont]

Double check your service URL in the Live CallerID Lookup app extension.
You might be making a request to /config but I think you should be making a request to /pir/config, because your service URL is supposed to be https://osbstage.twmsolution.com/pir

[Alan-Cheng]

Thank you so much for your detailed help and patience—it’s really appreciated! 🙏

Following your suggestion, here is my current configuration:

var context: LiveCallerIDLookupExtensionContext {
    LiveCallerIDLookupExtensionContext(
        serviceURL: URL(string: "https://osbstage.twmsolution.com/pir")!,
        tokenIssuerURL: URL(string: "https://osbstage.twmsolution.com/pir")!,
        userTierToken: Data(base64Encoded: "*******")!)
}

Running this locally in Xcode works fine. However, when I call refreshPIRParameters, the try-catch block catches the following errors:

do {
    try await LiveCallerIDLookupManager.shared.refreshPIRParameters(forExtensionWithIdentifier: "com.*******.********.LiveCallerIDLookupExtension")
} catch {
    liveCallerMessage = error.localizedDescription
}

Errors received:

1. Couldn't communicate with a helper application.
2. Unable to query status due to errors: failed to fetch token key
3. Unable to query status due to errors: server error

<HTML><HEAD>
<TITLE>Access Denied</TITLE>
<HEAD><BODY>
<H1>Access Denied</H1>
You don't have permission to access
"http://www.example.com/config" on this server.<P>
Reference #18.ed3f2e17.1759457438.d119794
<P>https://errors.edgesuite.net/18.ed3f2e17.1759457438.d119794</P>

Do you have any idea what might be causing these errors, even though my serviceURL points to /pir?

Thanks again for your time and guidance!

[karulont]

Please reproduce the issue and collect a sysdiagnose and send it through feedback assistant. See https://developer.apple.com/bug-reporting/

You can then share the report ID here.

[Alan-Cheng]

Thank you for your quick and helpful response! I’ve reproduced the issue and submitted a sysdiagnose via Feedback Assistant. The report ID is: FB20585929.

Please let me know if you need any additional information.

Thanks again for your support!

[karulont]

From the system logs it seems like: http://www.example.com is used as the service URL.
Double check your extension implementation.
Maybe try to disable and re-enable your extension in the system settings to force it to reload the configuration.

[Alan-Cheng]

I’ve reviewed my LiveCallerIDLookupExtension, and I couldn’t find any reference to http://www.example.com/ in the code. Below is the Info.plist from the extension target. Could this issue be caused by a missing or incorrect configuration value?

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "[http://www.apple.com/DTDs/PropertyList-1.0.dtd">](http://www.apple.com/DTDs/PropertyList-1.0.dtd%22%3E)
<plist version="1.0">
<dict>
<key>EXAppExtensionAttributes</key>
<dict>
<key>EXExtensionPointIdentifier</key>
<string>com.apple.live-lookup</string>
</dict>
</dict>
</plist>

Currently, we’ve configured serviceURL and tokenIssuerURL to use https://osbstage.twmsolution.com/pir — is there any other place where this URL needs to be specified?

I’ve also tried repeatedly toggling the extension in system settings to force a reload, but the test still fails.
I’ve attached the relevant logs under report ID: FB20585929 for your reference.

Additionally, you previously mentioned:
We found a configuration issue where Apple's OHTTP relay limits the response size and returns a HTTP 502 error code.

Below are the values we submitted in the initial request form. Could any of these be causing the issue or require adjustment?

• Region: Asia
• Peak requests per second: 1
• Total requests per day: 30,000
• Expected request size: 5 KB
• Expected response size: 3 KB

Please let us know if any of these values might be problematic or if there’s anything else we should check. Thank you!

[Alan-Cheng]

We noticed an interesting behavior when enabling the Live Caller ID feature in the system settings.
Our app’s network traffic shows a request being sent to http://www.example.com/config, which fails with a 403 response.
In contrast, other apps downloaded from the App Store that implement the same Live Caller ID functionality send requests to https://gateway.icloud.com and receive a 200 response.
We are curious about what might be causing this behavior, as we have confirmed that our app does not configure or reference example.com anywhere.
This might not be very helpful, but we wanted to share it for your reference.