Documentation Mercado Libre
Check out all the necessary information about APIs Mercado Libre.
Documentation
Last update 06/04/2026
Monitoring
Event logging and auditing
Recommended events to log
- Authentication: successful login, failed login, logout, password changes, among others.
- Authorization: denied/granted access, permission changes, role changes, among others.
- Critical operations: configuration changes, data CRUD, transaction tracking, report generation, among others.
- Security: rate limits reached and errors generated by activation of a control.
✅ COMPLETE LOG EXAMPLE:
{
"timestamp": "2026-01-15T10:30:45.123Z",
"user_id": "12345",
"action": "view_order",
"resource": "order/67890",
"result": "success",
"ip": "192.168.1.100",
"request_id": "abc123-def456"
}
Important information to include:
- Timestamp: date and time in UTC.
- User: id of the user in question.
- Action: What was attempted?
- Resource: On what resource?
- Result: Success or failure.
- Source IP: IP address of the request.
- Request ID: unique identifier per request for correlation.
Information NOT to include:
- Passwords or tokens.
- Complete personal data (emails, phone numbers, addresses, among others).
- Financial data.
- Any other type of information considered confidential.
References
- OWASP Logging Cheat Sheet: security logging best practices.
- OWASP Logging Vocabulary: standard vocabulary for security logs.
- CWE-778 (Insufficient Logging): documentation on insufficient logging.
Glossary
| Term | Meaning |
|---|---|
| Log | Record of events that occur in your system. |
| Audit | Review of logs to verify what happened, when and who did it. |
| Timestamp | Time marker that indicates when an event occurred. |
| RequestID | Unique identifier to track a request throughout the entire system. |
| Security event | Security-relevant action: login, logout, permission change, access denied, etc. |
| Log retention | How long records are kept before deleting them. |
Anomaly management
| WITHOUT ANOMALY MANAGEMENT | WITH ANOMALY MANAGEMENT |
|---|---|
| You find out about the problem when a seller complains | You receive automatic alerts before it affects users |
| You don't know if there are ongoing attacks | You detect suspicious patterns in real time |
| You manually investigate each problem | The system automatically prioritizes and categorizes |
| You react late | You act proactively |
Types of anomalies
Not all anomalies are the same. Understanding the types helps you configure your alerts better:
Point anomalies:
A single event that deviates significantly from normal:
SECURITY MONITORING: ANOMALY DETECTION --------------------------------------------- NORMAL STATE: Frequency: 5-10 failed logins per hour ANOMALY STATE: Frequency: 500 failed logins in 1 minute TECHNICAL INTERPRETATION: Diagnosis: Possible brute force attack
Contextual anomalies:
An event that is normal in one context but anomalous in another.
SECURITY MONITORING: SCHEDULE ANALYSIS ------------------------------------------- NORMAL: High traffic from 9am to 6pm (business hours) ANOMALY: Same high traffic at 3am TECHNICAL INTERPRETATION: Diagnosis: Possible malicious automated activity or bot
Collective anomalies:
A group of events that together indicate a problem, even though individually they may seem normal.
SECURITY MONITORING: SUSPICIOUS EVENT SEQUENCE ------------------------------------------------------ DETECTED FLOW: 1. Successful login from Argentina 2. Password change 3. Email update 4. Login from Nigeria (5 min later) TECHNICAL ANALYSIS: Each event individually is normal, but the sequence indicates a possible account takeover.
Anomaly detection process
An effective detection system follows these phases:
ANOMALY DETECTION CYCLE (FEEDBACK LOOP)
-----------------------------------------------
[ 1 ] COLLECT DATA
- Logs, metrics and system events.
^
|
[ 2 ] ESTABLISH BASELINE
- Define parameters of "Normal" behavior.
|
v
[ 3 ] DETECT DEVIATION
- Real-time comparison against the baseline.
|
v
[ 4 ] ALERT
- Immediate notification to the security team.
|
v
[ 5 ] RESPOND
- Investigation, containment and escalation.
|
v
[ 6 ] IMPROVE / ADJUST
- Refine thresholds and detection logic.
|
+------- SYSTEM FEEDBACK -------+
Phase 1: Collect data
- Centralize logs from all your services.
- Include: access, errors, transactions, configuration changes.
- Use structured format (JSON) to facilitate analysis.
Phase 2: Establish baseline
- Define what "normal behavior" is for your application.
- Consider: time of day, day of week, seasons (e.g.: Hot Sale).
- The baseline must be updated periodically.
Phase 3: Detect deviations
- Compare current metrics vs baseline.
- Use statistical methods (Standard deviation, percentiles).
- Consider machine learning for complex patterns.
Phase 4: Alert
- Notify the right team (Slack, email, PagerDuty).
- Include sufficient context to act.
- Prioritize by severity.
Phase 5: Respond
- Investigate the root cause.
- Escalate if necessary.
- Document findings.
Phase 6: Improve
- Adjust thresholds to reduce false positives.
- Add new metrics if you discover blind spots.
- Learn from each incident.
Suggested metrics for monitoring
PERFORMANCE AND SECURITY METRICS ----------------------------------------- Metric: MTTD (Mean Time To Detect) Description: Average time to detect an anomaly Suggested threshold: < 15 minutes Metric: MTTR (Mean Time To Respond) Description: Average time to respond Suggested threshold: < 1 hour Metric: False Positive Rate Description: % of alerts that are not real problems Suggested threshold: < 20% Metric: Alert Fatigue Score Description: Alerts ignored by the team Suggested threshold: < 5% Metric: Coverage Description: % of monitored systems/services Suggested threshold: 100%
Recommended tools
MONITORING AND OBSERVABILITY TOOLS ------------------------------------------ CATEGORY: Infrastructure monitoring Tools: Datadog, New Relic, Prometheus + Grafana Level: All CATEGORY: Centralized logging Tools: ELK Stack, Splunk, Loki Level: Intermediate CATEGORY: APM (Application Performance) Tools: Datadog APM, New Relic, Dynatrace Level: Intermediate CATEGORY: SIEM (Security focused) Tools: Splunk, Elastic SIEM, Sumo Logic Level: Advanced CATEGORY: Alerts Tools: PagerDuty, OpsGenie, Slack integrations Level: All INITIAL STRATEGY (LOW COST): - Prometheus + Grafana (open source) - ELK Stack (open source) - Alerts via Slack webhooks
References
- OWASP AppSensor: real-time attack detection at the application level.
- NIST SP 800-137: continuous information security monitoring.
Glossary
| Term | Meaning |
|---|---|
| Anomaly | Unusual or unexpected behavior in your system (e.g.: error spike, strange access patterns). |
| Baseline | Baseline of "normal" behavior against which to compare to detect anomalies. |
| Alert | Automatic notification when an anomaly is detected or a threshold is exceeded. |
| Threshold | Defined limit that, when exceeded, triggers an alert (e.g.: more than 100 errors/minute). |
| Dashboard | Visual panel that shows metrics and system status in real time. |
| False positive | Alert that triggers but does not correspond to a real problem. |
| SIEM | Security Information and Event Management - System that centralizes and analyzes security logs. |
Next: Incident management.