FHm that looks like a weird problem I have not seen in a while 
@buzziebee can you share your zitadel/proxy config?
My hunch would be that zitadel somehow does not read the config correctly... you should see the url printed at startup if it is correctly read
@buzziebee can you share your zitadel/proxy config?
My hunch would be that zitadel somehow does not read the config correctly... you should see the url printed at startup if it is correctly read
FHm not from the top of my mind.
What do you see when zitadel starts? Does that URL look the same as the externaldomain?
What do you see when zitadel starts? Does that URL look the same as the externaldomain?
Fok its good to know that this is the same.
What happens if you trigger a password reset, is the mail wrong in these mails?
The only thing I could comprehend would be if emails would be delivered before the domain was set.
What happens if you trigger a password reset, is the mail wrong in these mails?
The only thing I could comprehend would be if emails would be delivered before the domain was set.
FHm I think we pass on the domain we get from the client
So you could try sending the domain as "host" header in the api call.
This also relates to some extent on this issue we have https://github.com/zitadel/zitadel/issues/8279
So you could try sending the domain as "host" header in the api call.
This also relates to some extent on this issue we have https://github.com/zitadel/zitadel/issues/8279
GitHub
Current Situation ZITADEL currently selects the instance context based on a HTTP header (see order below) and checks it against the list of instance domains. Let's call it instance or API domai...
FHey, with grpc it might be the authority header (since it uses http2) kind of tricky to tell since the libs and proxies do some magic here
FAnd yeah there is an openapi spec, you should find some guidance here https://zitadel.com/docs/apis/introduction
ZITADEL exposes all features via different gRPC and REST APIs and provides SDKs for popular languages and frameworks.
FGood to know.
The openapi spec should be exposed by zitadel for example https://zitadel.cloud/openapi/v2/swagger/v2/zitadel/zitadel/
The openapi spec should be exposed by zitadel for example https://zitadel.cloud/openapi/v2/swagger/v2/zitadel/zitadel/
Fwhat problems do you see with gRPC?
FHm I see, that is not great yeah.
Need to think about a good solution for these cases
Need to think about a good solution for these cases