Different response schema on webhooks-endpoint


as stated in the Core API Concepts: All success/error responses follow the same schema.

Maybe I’m missing the point in the documentation, but the error and success responses from the webhooks-endpoint differ from all others.

Example forcing an error due to a non-reachable subscription-url:

"status": "error",
"success": false,
"errors": {
    "subscription_url": {
        "0": "invalid or non-reachable URL"

Example of a success response:

"status": "ok",
"success": true,
"data": {
	some more data...
	"additional_data": { }

Maybe you should mention this schema-difference in the documentation or update the schema thus it matches all other error/success responses.

Definitely a valid point.
Unfortunately we can’t change the error response, but we may add error and error_info to this.
The status response for Webhooks is far from perfect, but this won’t be changed for the time being. Certainly something to continue to think about for the future.

Hey @David,

I’m not sure if the following issue is related to my first statement in this thread, but since last thursday (2018-01-25) the webhook-endpoint seems to be down (at least for my account). Calling /webhooks via GET is always returning a non-standard 404 error:


Note that the particular section in the UI shows all registered webhooks. Only using the API (regardless whether I’m using my own client or the API Reference) throws the error.

Is this a general issue or only in my account?

Hey @Jan, it looks like this is an CORS issue with the API-docs.
I believe you’re using company.pd.com/v1/webhooks which won’t work. but company.pd.com/api/v1/webhooks or api.pd.com/v1/webhooks should work fine for you.

Thanks @David, it was indeed the case that i used company.pd.com/v1/ as base-url for all my api-calls. Changing it to company.pd.com/api/v1/ fixed that issue. Your answer saved me a lot of time.
But I’m still wondering that only GET /webhooks failed and all other actions on different endpoints worked as expected…I even could successfully register new webhooks with the wrong base-url.