StartIdentityProviderIntent gRPC Issue

The gRPC

StartIdentityProviderIntent

StartIdentityProviderIntent

StartIdentityProviderIntent

StartIdentityProviderIntent endpoint returns an empty response (only

details

details

details

details field) when using service account JWT authentication, but the REST API equivalent (

POST /v2/idp_intents

POST /v2/idp_intents

POST /v2/idp_intents

POST /v2/idp_intents) works perfectly with the same auth.

What We Tried

gRPC with service account auth → Empty response
REST API with service account auth → Works!

## Server Logs

level=debug msg="could not check projectID and origin of clientID (might be service account)"
clientID=helveston-backend-mgmt-api
error="ID=QUERY-Fdfax Message=Errors.App.NotExisting"

level=debug msg="could not check projectID and origin of clientID (might be service account)"
clientID=helveston-backend-mgmt-api
error="ID=QUERY-Fdfax Message=Errors.App.NotExisting"

level=debug msg="could not check projectID and origin of clientID (might be service account)"
clientID=helveston-backend-mgmt-api
error="ID=QUERY-Fdfax Message=Errors.App.NotExisting"

level=debug msg="could not check projectID and origin of clientID (might be service account)"
clientID=helveston-backend-mgmt-api
error="ID=QUERY-Fdfax Message=Errors.App.NotExisting"

Is the gRPC endpoint intended only for user-session context, while backend services should use the REST API? The docs don't clarify this distinction.

Workaround

We're using the REST API instead:

POST https://zitadel-instance/v2/idp_intents
Authorization: Bearer <service-account-jwt>
{
  "idpId": "idp-id",
  "urls": {
    "successUrl": "...",
    "failureUrl": "..."
  }
}

POST https://zitadel-instance/v2/idp_intents
Authorization: Bearer <service-account-jwt>
{
  "idpId": "idp-id",
  "urls": {
    "successUrl": "...",
    "failureUrl": "..."
  }
}

POST https://zitadel-instance/v2/idp_intents
Authorization: Bearer <service-account-jwt>
{
  "idpId": "idp-id",
  "urls": {
    "successUrl": "...",
    "failureUrl": "..."
  }
}

POST https://zitadel-instance/v2/idp_intents
Authorization: Bearer <service-account-jwt>
{
  "idpId": "idp-id",
  "urls": {
    "successUrl": "...",
    "failureUrl": "..."
  }
}

This works perfectly and returns the expected

formData

formData

formData

formData for SAML POST binding.

---

Environment: Zitadel v4.2.0 protobuf definitions, self-hosted Docker, SAML 2.0 IdP

Slightly concern about using a REST API workaround given the deprecation notice?

Ask Inkeep•10/28/25, 4:56 PM

Hi @nicjac, I'm an AI assistant for ZITADEL. While a team member reviews this question, I'll see if I can find relevant sources for your question.

Ask Inkeep•10/28/25, 4:57 PM

Answer

I wasn't able to find a direct answer in the available documentation about the specific behavior difference between the gRPC

StartIdentityProviderIntent

StartIdentityProviderIntent

endpoint and the REST API equivalent when using service account JWT authentication.

The documentation confirms that service users can authenticate using private key JWT (1) , and the Identity Provider Service V2 API exists (2) (3) , but doesn't explicitly address:

Whether

StartIdentityProviderIntent

StartIdentityProviderIntent

is intended only for user-session contexts

Why the gRPC endpoint returns empty responses with service account auth while REST works
The intended authentication context differences between gRPC and REST endpoints

Your workaround using the REST API with service account JWT appears to be functioning correctly based on the authentication patterns described in the documentation (1) .

For clarification on this specific endpoint behavior and the deprecation concerns you mentioned, I'd suggest clicking the "Ask for help" button to tag a team member who can provide authoritative guidance on:

The intended authentication contexts for this endpoint
Whether your REST API approach is the recommended pattern
Any implications of the deprecation notice you referenced

Would you like a general answer based on my knowledge instead?

Ask Inkeep•10/28/25, 4:57 PM

To learn more, see the sources I considered:

[1] Configure private key JWT authentication for service users
[2] Get identity provider (IdP) by ID
[3] Get identity provider (IdP) by ID

Ask Inkeep•10/28/25, 4:57 PM

Feel free to tag @Ask Inkeep with additional questions.

AAsk Inkeep To learn more, see the sources I considered: [[1] Configure private key JWT a...

Ask InkeepAPP•10/28/25, 4:58 PM

Got it. Tagging @Rajat for additional help.

Rajat•10/28/25, 10:11 PM

hey @nicjac you can still continue working with REST API endpoint for now as altho it has been marked for deprecation, it hasn't been deprecated YET(we'd make an announcment beforehand in the community) as for the grpc, I will take a look at it and will get back to you.

nicjacOP•10/29/25, 9:44 AM

Thanks, that would be super helpful! Everything else in our integration uses gRPC so it would be great to migrate this call as well. But after spending a day trying to make it work, I couldn't manage to do it. It seems to complain that we are using a service user, but it's the whole point for this particular endpoint. Some we're a bit confused!

Nnicjac Thanks, that would be super helpful! Everything else in our integration uses gRP...

Rajat•10/29/25, 2:26 PM

hey @nicjac I will check with my team , it should have worked just like every other endpoint. I will check with my team, should have not happened in the first place. I am on vacation until Friday so I will check back on it on Monday.