# How to tell whether your integration actually worked **URL:** \ **Category:** How Tos\ **Created:** [September 24, 2026, 5:39pm UTC](https://community.nextw.com/t/how-to-tell-whether-your-integration-actually-worked/2211 "2026-09-24T17:39:40Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![Kailey](https://sea1.discourse-cdn.com/flex001/user_avatar/community.nextw.com/kailey/32/266_2.png) [@Kailey](https://community.nextw.com/u/Kailey)\ **Post date:** [September 24, 2026, 5:39pm UTC](https://community.nextw.com/t/how-to-tell-whether-your-integration-actually-worked/2211/1 "2026-09-24T17:39:40Z")
When an integration with an external system doesn’t produce the result you expected, the underlying question is usually some version of “did my call go through.” That’s really three separate questions, and Nextworld gives you a different application to answer each one. **Outbound calls, Nextworld calling out to you or another system** Start with the Endpoint Log Inquiry application. It shows the fully resolved URL, headers, the request body, the response code, and the response body, for both successful and failed calls. By default only failures are logged, turn on logging for successes on the individual endpoint definition if you need the full picture. Logs are purged after 5 days, so pull what you need while it’s fresh. The response code is usually the fastest way in. The standard HTTP codes apply here the same way they do anywhere else on the web, a 400 means the request itself was malformed, a 401 means the credentials weren’t accepted, a 403 means the credentials were valid but not authorized for that action, and a 404 means the endpoint or resource wasn’t found. The exact description text in the response body varies by the external system you’re calling, so treat the code as the reliable part and the message as a hint. _Required role: SYS - Integration Developer._ **Inbound events, an external system sending something into Nextworld** This is where it gets less obvious. Start with the Webhook Log Inquiry application, which shows whether the inbound request itself was received and validated. Like endpoint logs, only failures show by default, turn on logging for successful events in the Webhook Setup record if you want to see the full history. Here’s the part that trips people up. A webhook logging successfully only means the request made it in the door. From there, it still has to be mapped into an event definition and routed to a target, often a logic block that actually does something with the data. That hand-off can fail even when the webhook itself looks completely healthy. To check it, use the Event Target Delivery Status Inquiry application, which shows the delivery status of the event to its target, and the Event Status Inquiry application, which shows the status of the event itself and lets you resubmit a failure once you’ve fixed the underlying issue. If everything in both of those looks fine and the result still isn’t what you expected, the next place to look isn’t a log at all, it’s configuration. Confirm the Webhook Definition, Webhook Setup, Event Definition, and Event Rule Definition records are set up the way you expect. The event rule is what actually maps the incoming payload to its logic block target, so a rule that’s filtering more aggressively than you intended, or pointing at the wrong target, will quietly produce nothing even though every log up to that point says success. _Required roles: Webhook Log Inquiry requires the SYS - Integration Developer role._ **Inbound calls that skip the webhook feature entirely** Not every inbound call is a webhook. Every logic block and every table exposes its own REST endpoint, so an external system can call one of those directly, without going through the webhook feature at all. If that’s the pattern you’re troubleshooting, look at the System Log Inquiry application instead, filtered to the Inbound API Request activity type. It’s a broader tool than the other logs here, it also captures logic block execution, database errors, and general REST API activity across the platform, at Info level and up, which is always on. If you need more detail than that, Debug level logging can be turned on for up to 8 hours per activity type through the System Log Configuration application, though it’s off by default and retained data only goes back 7 days either way. One thing it won’t give you, at any level, is the request or response body, Nextworld doesn’t record that here, for size and data security reasons. If you need the actual payload for a call like this, System Log Inquiry isn’t where you’ll find it, lean on correlation ID and timestamp to trace what happened downstream instead. Here’s what you actually do with the record once you’ve found it. Start with the status code on the Inbound API Request entry itself, that tells you whether the call succeeded or failed at the HTTP level, the same way a response code does in Endpoint Log Inquiry. If the call triggered a logic block and that logic block errored, you’ll find a second entry at Warning or Error level with the logic block name, the error message, and its execution context, both levels are always on, so you don’t need to enable anything to see it. Match the two by correlation ID, which is always present, either the caller sent one in or Nextworld generated one at the entry point, and every downstream activity from there carries it. Once you’ve confirmed what happened and why, check Audit Log the same way you would for any other path, to see whether the record actually changed. _Required roles: SYS - System Logging Viewer for the Inquiry application, SYS - System Logging Admin for the Configuration application._ **Confirming the data actually landed** Logs tell you whether a call or event was processed. They don’t tell you whether the record you expected to see actually changed. For that, use the Audit Log application. It’s not an integration-specific tool, it tracks changes to any record for any reason, which is exactly why it’s useful here, it’s the one place that shows you the ground truth regardless of what path the data took to get there. _Required role: SYS - Security Administrator._ **Tying it all together** Correlation ID is the strongest tool you have for this, more than the documentation alone lets on. It always exists, if the calling system doesn’t pass one in, Nextworld generates one at the entry point, and every downstream activity triggered from there, synchronous or asynchronous, carries that same ID. Add the Correlation ID field to the list view in any of the inquiry applications and you can visually line up every record tied to one event, across every application it touched. Timestamp is still a reasonable first pass when you don’t have a specific record to start from, but correlation ID is what actually proves you’re looking at the same event and not just a coincidentally close one.