# Locally Simulate HTTP Requests

Source: https://dev.arcxp.com/integrations/manage-integrations/locally-simulate-http-requests/

This guide will get you familiar with writing code in an integration and invoking that code on your local machine.

This guide will get you familiar with writing code in an integration and invoking that code on your local machine.

[Asynchronous events](https://dev.arcxp.com/integrations/events/ifx-events/#event-types) originating from the Event Registry cannot be sent from non-local environments to your local machine. To test locally, you can simulate an event by calling the HTTP endpoint that IFX provides.

## Prerequisites

- You have an integration set up locally with a handler prepared to receive events. If you do not, [Creating Handlers to Receive Events with IFX](https://dev.arcxp.com/integrations/manage-integrations/creating-handlers-to-receive-events-with-ifx/) will walk you through it.

## Run a local server

To spin up a local server where local code can be tested, issue the command `npm run localTestingServer`

When the server has started successfully, it will look like this:

Terminal window

```bash
> @myorg/myorg-my-ifx-integration@1.0.0 localTestingServer
> node node_modules/@arcxp/arcxp-ifx-node-sdk/localTestingServer

Loading environment configuration for env:  development
Local Express Server Started at http://127.0.0.1:8080/ifx/local/invoke
```

`http://127.0.0.1:8080/ifx/local/invoke` can now be used to POST event messages to and invoke integrations locally.

> **Tip:**
> 
> `Ctrl + C` will terminate a running server.

## Event payload model

All events, except for custom events, will have the same fundamental structure:

```json
{
  "organizationId": "string",
  "key": "string",
  "typeId": "int",
  "uuid": "string",
  "currentUserId": "string",
  "version": "int",
  "invocationId": "string",
  "body": {"PAYLOAD BODY HERE"}
}
```

The `body` serves as the designated area for event data, and its structure can be customized to meet any specific requirements by the event originating application.

For example, the `websked:edition_finalize` [event](https://alc-swagger-template.s3.amazonaws.com/docs/swagger/ifx/admin/event-menu/index.html#websked) will send the following event message:

```json
{
  "organizationId": "myorgname",
  "key": "websked:edition_finalize",
  "typeId": 1,
  "uuid": "",
  "currentUserId": "",
  "version": 2,
  "invocationId": "ABCD-123534R4-DAFSDFA-8363",
  "body": {
    "type": "edition_finalize",
    "orgId": "string",
    "publication": {
      "name": "string",
      "publicationId": "string",
      "editionId": "string",
      "editionTime": "number",
      "editionUrl": "string",
      "storyIds": [
        "string"
      ],
      "sectionId": "string",
      "website": "string",
      "publicationSetId?": "string"
    }
  }
}
```

## Test it out

Let’s take a very simple (made up) event message so we can see it working:

1. Navigate to the integration directory where you have a handler ready to go. You can have something as simple as:  
src/eventsHandlers/updateHandler.js  
```js
const updateHandler = async (event) => {
  console.log(event)
  console.log("inside story updateHandler")
  return "hooray!"
}
module.exports = updateHandler
```
Make sure you included the event name and handler in `src/eventsRouter.json`:  
```json
{
  "updateHandler": [
    "story:update"
  ]
}
```
2. Start local server `npm run localTestingServer`
3. Use Postman (or cURL) to POST a payload to the local server `POST http://127.0.0.1:8080/ifx/local/invoke/` and include the JSON below as the POST body:  
```json
  {
    "organizationId": "myorg",
    "key": "story:update",
    "version": 2,
    "invocationId": "12345678-90ce-4e72-bf72-10bfb0e4186d",
    "body": {
        "my_data": "Hello!!!!!"
    }
  }
```
In the Postman console we can see the return message from our handler code:  
![Postman response example](https://dev.arcxp.com/images/ifx/handlerReturn.jpg)  
and back in our code editor, the result of `console.log(event)`:  
![code editor logging event.body.my_data](https://dev.arcxp.com/images/ifx/consoleOutput.jpg)

## How to get a “real” payload model

Each application that sends events to IFX defines its own payload inside of the `event.body`, such as [Composer's Send to Print](https://alc-swagger-template.s3.amazonaws.com/docs/swagger/ifx/admin/event-menu/index.html#composer) event.

You can get the payload model of events you are trying to simulate from the [Event Menu](https://alc-swagger-template.s3.amazonaws.com/docs/swagger/ifx/admin/event-menu/index.html). In cases where the payload is not provided:

1. Create test event handlers for each event you are researching so you can console log the event payload
2. Map those events to the handler
3. Ensure useful logging is in place i.e. `console.log(event)`
4. Bundle, deploy and promote the integration to Sandbox
5. Trigger the event you need by performing an action, such as updating a story
6. [Query the logs](https://dev.arcxp.com/integrations/logs-metrics/integration-logs-ui/) to view the payload

Save the payload so you can easily adjust minor data points locally, like the headline, to generate new scenarios.

---
  
Have a feature request or suggestion? Let us know on [Our Ideas Portal](https://ideas.arcxp.com/?project=IFX).