# Integration with your server

### Introduction

Panacea Mobile’s USSD gateway also allows you to fetch plain text from a web address and display it to a user when they dial your USSD string. User responses can also be pushed back to this address and fetch new text to display, effectively giving you complete control of the campaign/service from your own server. This is called a **Proxy Campaign**.

### Setting up a Proxy Campaign

When setting up a new USSD campaign from your Panacea Mobile Account Dashboard, select **Proxy Campaign** from the **Campaign Type** drop-down menu on the **New Campaign** modal window. This will reveal a new text field to paste the URL that must be called when a new USSD session is started.

What this will do is, when users enter that node, the text they see will be provided by your server, and when they respond there will be no response matched and call your server for the ‘error’ text, essentially creating a proxy. Once you are ready to end the session with the user you will need to include the header in your response headers:

```
X-ussd-close: 1
```

Our service will then close the session with the user and allow no further responses.

### HTTP Requests

Panacea Mobile’s USSD service can make HTTP requests to your own server to fetch plain text to display on a node in the following scenarios:

* You have selected 'Text from URL' as a response type on a node
* You have chosen 'Text from URL' as a response type for error text on a node
* You have created actions of 'HTTP Request' on your node

### Text from URL Request

When you have selected text from the URL as a response type, the Panacea Mobile USSD service will connect to your server to determine what content to show the user.

The request will contain the following data in the query string.

<table><thead><tr><th width="274">Variable</th><th width="114">Type</th><th>Description</th></tr></thead><tbody><tr><td><code>ussd_msisdn</code></td><td>String</td><td>This is the phone number of the user, in international format, eg: 27831234567</td></tr><tr><td><code>ussd_session_id</code></td><td>String</td><td>This is the unique session ID for the current user session. This will be the same for multiple requests (if applicable). Allowing upstream applications to have context as to where the users are.</td></tr><tr><td><code>ussd_request</code></td><td>String</td><td><p>This is what the user input was. If it was the start of the session it would be the string (eg: *100*123#). If it was a response it will be their response. ussd_type – integer This is the type of request. Types are:</p><p></p><p>1 = New session starting </p><p>2 = User response </p><p>3 = User closed session </p><p>4 = Session timed out. </p><p>If the user closes the session or the session times out, the last active node will be called (if it is/was a response URL type).</p></td></tr><tr><td><code>ussd_node_id</code></td><td>Integer</td><td>This is the unique node ID that is currently being processed.</td></tr><tr><td><code>ussd_node_name</code></td><td>String</td><td>This is the given node name that is currently being processed.</td></tr><tr><td><code>ussd_response_{NodeName}</code></td><td>String</td><td>All previous responses will be added to the URL string with the name of the relevant node. For example if a node named ‘User Gender’ was responded to with ‘Male’ in a session, it would be included in the URL query string as ‘&#x26;ussd_response_User_Gender=Male’. This is not just the last node but all responses in the session.</td></tr></tbody></table>

### Error text from URL Request

This request is the same structure as a standard Text from a URL request.

### HTTP Request action

This request is the same structure as a standard Text from URL request.
