activity_history
Preview: in development.
activity_historyis not yet generally available and is not enabled on customer applications. This page describes the planned behaviour so that you can prepare your integration. Field names, values and coverage may change before release. To join the pilot, contact your Plumma account manager.
The activity_history command estimates how long the current holder has had a mobile number. It is built only from activity logged on the number (SMS, voice, verification checks), not from the operator's activation record. It returns when activity was first observed, when the current period of continuous use began and how long it has lasted, and the tenure of the current holder in months.
Mobile numbers are recycled. After a long period of inactivity, an operator can reassign a number to a new subscriber. A gap of 180 days or more with no activity, the minimum inactivity the Philippine regulator (NTC) requires before a number can be reassigned, means the number may have passed to a new holder, so activity before the gap may belong to someone else. It is a signal, not proof: the same holder returning after a long break looks the same.
Unlike tenure_period, which asks the operator whether a contract is older than a given period, activity_history needs no operator authorisation and no input other than the number.
Response Reference
| Field Name | Data Type | Output Values | Description |
|---|---|---|---|
| activity_history | JSON block | oldest_record |
Block containing the activity history of the number. omitted → if no activity is on record for the number, or if the service returns "status": 1 or 2. |
| oldest_record | String | yyyy-mm-dd | Date of the first recorded activity on the number. Observed history, not the activation date. |
| current_tenant_start | String | yyyy-mm-dd | First activity after the most recent gap of 180 days or more with no activity. Equal to oldest_record when there is no such gap. |
| tenant_days | Integer | >= 0 | Days from current_tenant_start to the date of the request. 0 → first new activity after 180+ days of silence: the strongest sign of a recycled number. |
| tenure_min_months | Integer | >= 0 | Completed months from current_tenant_start to the date of the request. The tenure if the last 180+ day gap marked a new holder: the conservative figure, to use for scoring. |
| tenure_max_months | Integer | >= 0 | Completed months from oldest_record to the date of the request: the tenure if the number never changed holder. Values of about 48 months or more should be read as "at least". |
| tenure_band_months | String | 0-1, 1-2, 2-3, 3-6, 6-9, 9-12, 12-18, 18-24, then 6-month steps (24-30, 30-36…) |
The band that contains tenure_min_months. The lower bound is included: exactly 6 months falls in 6-9. |
| status_message | String | activity_history AUTH FAILED | activity_history AUTH FAILED → returned when only activity_history is requested and the command is not enabled for your application. |
Months are completed calendar months: 21 March to 21 October is 7 months, 21 March to 20 October is 6.
Reading the result
Use tenure_min_months, or its band, as the holder's tenure. It never overstates how long the current holder has had the number.
- tenure_min_months equals tenure_max_months. One continuous history with no 180+ day gap: the strongest tenure evidence.
- tenure_min_months well below tenure_max_months. The number went silent for 180+ days at some point. The true tenure is the minimum if the number changed holder at the gap, the maximum if the same holder came back. Treat activity before current_tenant_start as possibly someone else's.
- Band 0-1 or tenant_days = 0. The number has just come back after six months or more of silence: the highest recycling risk.
- No activity_history block. No activity on record. Treat it as unknown, not as zero tenure.
Note: oldest_record is the first activity observed, not the date the SIM was activated, and the recorded history becomes dense only from mid-2022. A gap of 180 days or more points to a possible new holder; it does not prove one.
Summary Table
| Command | Description | Response Values |
|---|---|---|
activity_history |
Estimates how long the current holder has had the number from its logged activity, and flags numbers that may have been recycled. Preview: not yet generally available. |
|
API reference
Request
curl -X POST "https://api.connect.plumma.it/services/api" \ -H "Content-Type: application/json" \ -H "x-plumma-connect-api-key: YOUR_API_KEY_HERE" \ -H "x-plumma-connect-app-id: YOUR_APP_ID_HERE" \ -d '{ "number": "+639171234567", "commands": [ "activity_history" ] }'
Response (continuous history)
{
"number": "+639171234567",
"status": 0,
"status_message": "Response from one supplier - This response is for demo purpose only [{activity_history=SUPPLIER0 : Success}]",
"activity_history": {
"oldest_record": "2022-10-21",
"current_tenant_start": "2022-10-21",
"tenant_days": 1461,
"tenure_min_months": 48,
"tenure_max_months": 48,
"tenure_band_months": "48-54"
},
"version": "1.0.2-20261025113434"
}Response (gap in activity)
{
"number": "+639171234568",
"status": 0,
"status_message": "Response from one supplier - This response is for demo purpose only [{activity_history=SUPPLIER0 : Success}]",
"activity_history": {
"oldest_record": "2022-06-24",
"current_tenant_start": "2025-07-03",
"tenant_days": 475,
"tenure_min_months": 15,
"tenure_max_months": 51,
"tenure_band_months": "12-18"
},
"version": "1.0.2-20261025113434"
}Response (no activity on record)
{
"number": "+639171234569",
"status": 4,
"status_message": "Response from one supplier - This response is for demo purpose only - Commands [activity_history] were routed but returned no data",
"version": "1.0.2-20261025113434"
}Response (unauthorized)
{
"number": "+639171234569",
"status": 2,
"status_message": "activity_history AUTH FAILED",
"version": "1.0.2-20261025113434"
}Read this in the portal, with search and the reference beside it: Activity History