Ranking Partner Trigger icon

Ranking Partner Trigger

Handle RankingPartner API webhooks

Overview

This node acts as a webhook trigger for the Ranking Partner API, specifically designed to handle incoming webhook requests related to Ranking Partner events. It validates incoming requests using a token and then passes the received event data into the workflow. This node is useful when you want to automate workflows based on specific events from the Ranking Partner system, such as invoice creation notifications.

A practical example would be automatically processing or logging invoices whenever a "PayPro Invoice Created" event is received, enabling seamless integration between Ranking Partner and other systems without manual intervention.

Properties

Name Meaning
Token The secret token used to validate incoming webhook requests to ensure they are authorized.
Event The type of event to listen for. Currently supports: "PayPro Invoice Created".

Output

The node outputs the JSON payload received from the webhook request in the json field of the output data. This payload contains the event data sent by the Ranking Partner API.

No binary data output is produced by this node.

Dependencies

  • Requires an HTTP POST webhook endpoint exposed by n8n.
  • The user must provide a valid token that matches the x-api-key header in incoming requests for authentication.
  • No external API calls or additional credentials are required beyond the token validation.

Troubleshooting

  • Unauthorized Error (401): If the token provided in the node configuration does not match the x-api-key header in the incoming request, the node will respond with a 401 Unauthorized error and stop execution. Ensure the token configured in the node matches exactly the token sent by the Ranking Partner webhook.
  • Missing or Incorrect Headers: If the x-api-key header is missing or malformed, the request will be rejected. Verify that the webhook sender includes this header correctly.
  • Event Filtering: Although the node has an "Event" property, the current implementation does not filter events internally; it simply outputs whatever payload is received. Users should implement any event-specific filtering downstream if needed.

Links and References

Discussion