Yes, it is an input (query param) as it needs to be passed in when more records are to be returned.
/customer/account/{accountId}/transactions:
get:
description: Returns all checking account transaction data from the system of record
operationId: findCheckingAccountTransactionsByAccountId
produces:
- application/json
- application/xml
- text/xml
- text/html
parameters:
- name: accountId
in: path
description: accountId to use in the operation
required: true
type: integer
format: int32
- name: accountTypeCode
in: query
description: indicates IM or ST
required: true
type: string
- name: filter
in: query
description: filter criteria
required: false
type: string
- name: nextKey
in: query
description: used to call the next 100 records
required: false
type: integer
format: int32
The key also needs to exist in the response as it will indicate if there are more records to be returned.
So in the response we might have something like this if I'm envisioning it correctly
{key, "12345678"} <<<<This is the one I don't feel like I have modeled properly. The response array for transactions seems to be in place similar to as shown in the petstore sample.
"transactions": [
{date: 02282015, desc: "purchase store X",amount: 1.00,balance: 19.00,transactionType: "CHECKING"},
{date: 02282015, desc: "purchase store X",amount: 2.00,balance: 17.00,transactionType: "CHECKING"},
{date: 02282015, desc: "purchase store X",amount: 3.00,balance: 14.00,transactionType: "CHECKING"},
{date: 02282015, desc: "purchase store X",amount: 4.00,balance: 10.00,transactionType: "CHECKING"},
]