It's vital to configure webhooks to ensure your app can receive updates for the Ads API.

You can easily self-configure the webhook events that are called, and to which URL. Symphony's API will send POST requests to your endpoint with the payload structure outlined further in this page.

Steps to Configure:

Make the following call to the Sandbox or Production API, along with your

curl -X POST {{PARTNER_API}}/webhook \
-H "Content-Type: application/json" \
-d '{
  		"url": "https://webhook.site/64ea010c-81e3-4df4-9844-49ec8704ad18/update",
  		"events": [
					"campaign.updated"
 			 ]
		}'

Your payload should include these body params:

url: your url where you want to receive the webhook
events: this is an array of events you want the specified url. You can pass every event possible if you want a single endpoint to receive every webhook, alternatively you can set multiple url for only the type of events you want it to receive. The

{
	"url": "https://webhook.site/64ea010c-81e3-4df4-9844-49ec8704ad18/update",
	"events": [
		"campaign.updated"
	]
}

Once you have a webhook configured, execute one of the corresponding flow and wait to receive the updates.

Event types

Webhooks are sent with an event field, which defines the type of action or change made for an entity. The following events are called:

campaign.created
campaign.updated
campaign.failed
campaign.processing
campaign.completed

Requests

Each of these states sends a request with the POST method to the configured url.

In the body of the request, send:

event: the type of action or change made (ex: campaign.created)
The information of the entity that changed is also sent in the root of the payload. For example, for status changes of a campaign, the following is sent:
- provider: facebook or symphony, depending on the type of campaign that was configured
- type: Depending on the provider it could be:
  - facebook: *'boost_instagram'* | *'record_streams'* | *'link_clicks'*
  - symphony: *get_playlisted | increase_video_views*
- id: Campaign identifier
- reason: In case a state can change for more than one reason, this is specified in the reason field, for example, when a campaign updates the end date, the event field will be campaign.updated, and the reason end_date_changed
- metadata: Object with relevant information, comes in campaign.updated events
- status : The possible status of the campaign, although they are generally according to the eventfield
  - Possible statuses
```
  | 'DRAFT'
  | 'PROCESSING'
  | 'SUCCESS'
  | 'FAILED'
  | 'TO_RETRY'
  | 'PAUSED'
  | 'FINISHED'
  | 'ACTIVE'
  | 'ANTICIPATED_PAUSE'
  | 'IN_REVIEW'
```