I'm trying to setup a Metaplay web API endpoint to receive Webhook calls from an external service. It's not working, the verification call from the external service is not getting the right response. I do get it with a browser. Apparently the endpoints under /api don't just work with direct http calls but there is a 302 redirect from nginx in between. Using curl, the url also does not work, except when a cookie is given to make the redirect work. Is there a way to set up directly working http endpoints to implement listening to webhooks? I'm guessing it doesn't currently work due to the redirect. I figure a workaround is to set a webhook listener somewhere else, and call Metaplay from there, using a call which allows following redirects. But it would be nice to skip needing that extra service in between.

Hey, looks like this might be possible to arrange, but we'll double check and get you an answer on Monday! The person who might know best is on vacation this week 🌴

oh actually it might be about authentication, not redirect .. i thought my metaplay api endpoint was working without auth but my browser was ofc authenticated

The config is hosted in the cdn, so for the live game those requests never hit the server. The server config endpoint is just for local development. We have had some previous discussion on having public endpoints available, but yeah, the person is on vacation right now

ah ok i found public class MetaplaySystemHttpServer

Yeah, would be simplest if we can get the public endpoint set up for you

Hey hey, There's a few steps to get this to work: 1. In your Helm deployment file, you need to add a publicApiEndpoints elements, something similar to below.

publicApiEndpoints:
- hostname: {projectname}-{environment}-admin-endpoint.p1.metaplay.io
  target:
    root: "/webhook/"

I'd recommend to keep the -endpoint suffix and the /webhook/ root for now. 2. The ASP.NET controller needs to inherit from MetaplayWebhookController and the routes need to specify [AllowAnonymous] . For example a very simple implementation:

public class ExampleWebhookController : MetaplayWebhookController
    {
        public ExampleWebhookController(ILogger<ExampleWebhookController> logger, IActorRef adminApi) : base(logger, adminApi)
        {
        }

        [HttpGet("publicEndpoint")]
        [AllowAnonymous]
        public async Task<string> ExamplePublicEndpoint()
        {
            return "Hey, you can access this.";
        }
    }

Deploying this should then redirect https://{projectname}-{environment}-admin-endpoint.p1.metaplay.io/publicEndpoint to your controller. Keep in mind that your DNS might take a while to update, I had to manually flush mine on windows for it to work.

great, thanks! does this work also with the old version of the SDK? we didn't upgrade to latest yet but will soon. i might test this before that though

I think any recent version of the SDK should support this

@Jurjen should the public endpoints work when running the dashboard & server locally? my usual GameAdminApiController endpoints show under /api but i can't find the /publicEndpoint .. i tried this too, http://localhost:5551/webhook/publicEndpoint

uhh, I haven't tested it but it should just be a normal asp.net controller 🤔

my controller is now just exactly copy-paste from your example here

Ah right, 5551 is what the dashboard service exposes while 5550 is what the game server exposes

right-o. the usual admin api calls seem to be redirected or proxied by the dashboard or something, but these not, which is fine

By default the game server hosts the built dashboard as well on 5550, however because you want to develop it locally, pnpm dev runs some internal http server that automatically reloads.

ahh ok, i didn't know at all what the pnpm thing is doing there anyways, all seems to be good now! let's see if i still need a Lambda function to proxy the webhook calls, if the originating service does not follow redirects, but that's fine as i already made such a proxy lambda :p

I don't you'd have to, but not 100% sure tbh

cool maybe not needed indeed, curl at least works without the -L option which is afaik needed for redirects