Definition
Card information query retrieves an IoT SIM by ICCID, MSISDN, project, customer, or agent. A status board raises alerts on its own. This query is for someone who asks for one SIM, or for a batch, at the moment they need it.
How a search can be shaped
- Exact: One SIM by ICCID or MSISDN, returning status, plan, usage, and the bill.
- Filtered: Combine project, customer, agent, device type, activation time, and data plan type.
- Batch: Upload an ICCID list, or export the filtered set, as Excel.
What comes back
A result usually carries ICCID, MSISDN, and operator, the card lifecycle state, the current data plan, remaining data, data billing lines, and the project, customer, and agent the SIM belongs to. A consumer looks up their own SIMs in user self-service. An enterprise or an agent looks them up in the console. A live dashboard is for alerts. This query is for a search someone starts.
Speed, pages, and the export file
The table can be large, so ICCID and MSISDN need indexes. An exact lookup by ICCID or MSISDN should return quickly. A combined filter should page and cap the rows. A bulk export should build the file in the background so the request does not time out. The rows are used for reconciliation, reports, and support. Permissions have to limit each user to the SIMs they are allowed to see. The data comes from the platform database and from operator API sync, and it has to be current enough to trust.
Who searches, and what they are trying to settle
A consumer opens user self-service for status, plan, usage, and the bill on their SIMs. An agent opens the agent self-service portal for the SIMs they purchased. Support types an MSISDN or an ICCID and lands on the SIM behind a fault report. The same record is tied to card lifecycle, data billing, and operator reconciliation. That link is a basic capability of the IoT Cloud Platform.
Filters, and where the row comes from
An exact hit uses ICCID or MSISDN. A combined filter uses project, customer, agent, device type, activation time, and data plan type together. The row shows identity, card lifecycle state, the current plan, remaining data, and data billing detail. The caller only sees SIMs inside their permission. The values are stored on the platform and refreshed from the operator API.
Why the stored status and a live operator query can disagree
Card information query reads the copy the platform keeps for search, plus a live query to the operator when one is needed. The copy has a sync time. The user has just paid, the resume command has no receipt yet, and the query still shows suspended. That is not necessarily the wrong SIM. The result should carry “status updated at” and “usage bill period.” A status with no time cannot be used to decide whether the SIM can go online now. An exact query by ICCID should use a unique index. A query by number should first confirm which SIM that number is bound to now. An old number that has been replaced should return “replaced,” not a casual hit on a historical row. A bulk export is a snapshot from the moment the job was submitted. If another SIM is suspended while the file is being built, the file and the page disagree, and that is expected. The file header should carry the time it was generated. SimtoLink card information query keeps exact search, filtered search, and asynchronous export apart. An export job also has to apply the attribution scope of the person who queried.
How stacked filters decide which SIMs are actually in scope
Project, customer, agent, activation date, and plan are conditions that must all be true. They are not “any one of these.” If the API treats a condition that was not sent as an empty string and matches on equality, the result is zero rows, and the page looks as if the SIM does not exist. A condition that was not sent should mean no restriction. A date filter has to say whether it is the activation date, the stock-in date, or the expiry date. If those three dates share one “time” parameter, support will miss unactivated SIMs. The last six digits of a number are not an exact query. At most they are a controlled fuzzy search with a row limit, so the search does not scan the whole table. Returned fields are cut by role: the user sees the plan and the remaining allowance, support also sees the suspension reason, and finance also sees the bill. Do not put operator secrets or identity document numbers into the default detail just because an internal account finds it convenient. A failed query has to distinguish no permission, SIM not found, and operator API timeout. A timeout must not be displayed as “SIM not found.”
An export and a live alert are different jobs
A query is a person asking for data. An alert is data coming to find a person. Polling the query API as monitoring is slow, and it will exhaust the operator’s rate limit. Watching for suspension or for a low balance should follow status sync and thresholds, not have support query by SIM number every minute. A query result can carry the latest alert, but the alert list does not need every filter the query has. Usage in an export file is the total already stored at query time. It is not the network element’s count at this second. Before reconciliation staff compare an export with operator records, they align the bill period and the time zone. If the same identifier is stocked in again after reclaim, the query shows only the current life by default. Looking at the previous project requires an explicit history query, or usage from the old and new projects sticks to one SIM. History queries are authorized on their own. A front-line troubleshooting account cannot change a retired file by default. If an export job crosses the reclaim point, the file should mark which life that row belongs to, so two stretches of usage are not added on one row and handed to reconciliation.