Creating a service REST in Pega is one of those tasks where there is no wizard to hold your hand. Unlike Connect REST, where the wizard does most of the work, service REST requires you to manually create the integration classes, properties and activity before configuring the rule itself.
Once you understand the pattern, it moves quickly. Here is how it works.
The Scenario
We are exposing a GET endpoint that accepts a customer ID and returns fraud watchlist details stored in the claims application. The customer ID comes in through the resource path – not as a query string – and the response returns four fields: customer ID, customer name, fraud type and policy number.
Step 1 – Define the Integration Layer
Before writing any rules, decide where your integration class lives in the application stack. For something specific to the claims application, the integration class belongs at the application INT layer – not the org layer.
Step 2 – Create the Integration Classes and Properties
You need a class to hold the response structure. For a simple GET that reuses an existing data type, you can often point directly to the data layer class rather than creating a separate integration class with duplicate properties. Pega encourages reuse – if your response structure matches an existing data class, reference it directly. Only create a new integration class when you need a different structure.
For more complex responses with embedded objects and arrays, you will create integration classes that hold page properties – one page property per embedded object, one page list property per array. These map directly to the JSON objects and arrays in your response.
Step 3 – Create the Service Activity
Before building the service REST rule, create the service activity that does the actual work. This is important – you can test the activity independently before wiring it into the service.
The activity accepts the customer ID as a parameter, calls the relevant data page to retrieve the fraud details, and maps the results into the response properties on the primary page. Test it using the run option in Dev Studio and verify the clipboard contains the expected data. If the activity works cleanly in isolation, the service REST will work too.
Step 4 – Configure the Service REST Rule
Create the service REST rule under Integration – Services – Service REST. The create form is where the URI gets defined. Specify the service package, version and URI template. Customer ID should be marked as a variable in the URI template so it gets dynamically resolved at runtime.
Once created, set the resource primary class to your integration class. On the Method tab, expand GET, link the service activity, pass the customer ID parameter from the resource path, and configure the response mapping. Use JSON with fast processing to serialise the response properties directly into the JSON output without additional transformation steps.
Testing With Postman
Always test your service REST with Postman before handing it to a consumer. Provide basic authentication credentials – ideally a dedicated service account, never your own developer credentials. Pass the customer ID in the resource path and verify the response structure matches what you designed.
If something does not work, use the Trace option on the service REST rule in Dev Studio. It traces any incoming request and shows exactly where the execution fails. Common issues – extra characters in the URL from copy-paste, spaces in parameter values, class context mismatches in the activity.
The tracer will show you precisely what went wrong.
Watch the Full Walkthrough
In the video below I walk through every step live – creating the integration class, building the service activity, configuring the service REST rule, and testing end-to-end in Postman including debugging a real error using the service REST tracer.
GET is the foundation. Once you have this working cleanly, POST follows the same pattern with an additional request body. That is the next video.
